avr-gdb simulAVR (keine Verbindung -- Versionskonflikt?)

[D a v i d K. (oekel)]

Hi,

ich bekomme die beiden Tools bei mir nicht miteinander verbunden.
Soweit wie in Beitrag "simulavr und avr-gdb" komme ich 
erst garnicht.

Da das simulAVR aus meiner Ubuntu 18.04 Paketquelle den gewünschten 
Atmega644 nicht unterstützt habe ich aus
git clone https://github.com/Traumflug/simulavr.git
git checkout traumflug
nachinstalliert/gebaut

Nun hätte ich:
✗ simulavr --version
simulavr version 0.1.2.2
Copyright 2001, 2002, 2003, 2004  Theodore A. Roth.

✗ /home/***/simulavr_git/simulavr/src/simulavr --version
SimulAVR 1.1dev


✗ avr-gdb --version
GNU gdb (GDB) 7.11.1

=========================================
Folgendes führe ich in zwei Terminals aus:

1$ ✗ /home/****/simulavr_git/simulavr/src/simulavr -d atmega644 -g -p 
8888
Waiting on port 8888 for gdb client to connect...

2$ ✗ avr-gdb
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
[...]
Type "apropos word" to search for commands related to "word".
(gdb) file DentaGel2_9.elf
Reading symbols from DentaGel2_9.elf...fertig.
(gdb) target remote localhost:8888
Remote debugging using localhost:8888
Ignoring packet error, continuing...
Warnung: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb)

in einem dritten Terminal erhalte ich noch:
netstat -an | grep 8888
tcp        2      0 0.0.0.0:8888            0.0.0.0:* 
LISTEN
tcp        0      0 127.0.0.1:59290         127.0.0.1:8888 
FIN_WAIT2
tcp        0      0 127.0.0.1:59298         127.0.0.1:8888 
VERBUNDEN
tcp      650      0 127.0.0.1:8888          127.0.0.1:59290 
CLOSE_WAIT
tcp      142      0 127.0.0.1:8888          127.0.0.1:59298 
VERBUNDEN

Wobei das CLOSE aus einem vorigen Versuch stammt und das VERBUNDEN, wenn 
ich netstat schnell genug nach dem target remote angebe. (888 statt 1212 
übrigens weil ich irgendwo gelesen habe, dass gdb mit der Default-Config 
Probleme hätte)

Hat Jemand eine Idee für mich?
Die Überschrift kommt aus einer Vermutung die bei OpenOCD geäußert 
wurde.
Könnte das ein Grund sein? (Welche Versionen sollte ich stattdessen 
probieren?)

(Mein 1/4 Kernen läuft übrigends mit 11% und interner automatischen 
Übertacktung, sobald simulavr ausgeführt wird. Mein Laptop-Lüfter dreht 
ganz schön auf)

Und noch eine Info: Ich möchte simulavr in Betrief nehmen, da ich auf 
Geschäftsreise die Hardware nicht mitschleppen kann und wenn ich es 
richtig verstanden habe, dann tausche ich später einfach nur simulAVR 
gegen avrice aus. (Hätte also vorweg ähnliche Probleme ?!)

Grüße David

[Oliver S. (oliverso)]

Seit sehr langer Zeit enhalten die avr-gdb-Quellen auch den Simulator.

Probier einfach mal ein "target sim" im gdb.

Oliver

[D a v i d K. (oekel)]

Oliver S. schrieb:
> Seit sehr langer Zeit enhalten die avr-gdb-Quellen auch den Simulator.
>
> Probier einfach mal ein "target sim" im gdb.

Passt soweit, hier eine Doku:
https://sourceware.org/gdb/current/onlinedocs/gdb.html

somit wäre es
$/usr/bin/avr-gdb -eval-command 'target sim'
oder
$/usr/bin/avr-gdb -ex 'target sim'

Haben wir hier noch Jemanden, der mit Clion auskennt und mir sagen kann 
wie ich dieses Argument in die Configuration bekomme (siehe Anhang).
Es geht nämlich leider weder direkt hinter die ausführbare Datei noch 
als 'target remote' args:

Der Grund ist sicherlich, dass dies hier als REMOTE_DEBUG gedacht war.

Grüße David

[Oliver S. (oliverso)]

Das Zauberwort heisst .gdbinit

Oliver