Fehler bei Benutzung von gdb

Ja, mittlerweile lese ich hier auch wieder mit nach meinem Urlaub. :)
Du hättest natürlich auch eine email schreiben können, meine
Mailadresse ist ja kein Geheimnis.

Naja, der GDB braucht irgendwas, auf dem er überhaupt debuggen kann.
Auf dem Pentium oder was auch immer Deines PC kann er ja keinen
AVR-Code direkt ausführen.  Du brauchst entweder ein simulavr als
Backend für die Simulation oder ein AVaRICE als ,,Leim'' zwischen
dem AVR-GDB und einem JTAG-ICE.  Erst mit einem dieser beiden
Werkzeuge kann der AVR-GDB dann etwas tun.

Verbunden werden beide übrigens mittels TCP, ``target remote ...''.

Für die Geschichte mit timer_enable_int() gibt's mittlerweile bereits
einen Bugreport, da das schon jemand vor Dir entdeckt hat:

http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5454&group_id=2140

Das Beste ist, timer_enable_int() nicht mehr zu benutzen, es macht
ja ohnehin weiter nichts als die Zuweisung zu einem Register.  Das
werde ich in demo.c demnächst mal ändern.

Das stimmt schon, dass der gdb etwas braucht, auf dem er debuggen kann.
Aber sollte er nicht wenigstens mit 'list' den Inhalt der Datei
anzeigen, auch ohne mit SimulAVR verbunden zu sein?

Und wie kann ich gdb mit SimulAVR verbinden? Ich nehme an, man muss
SimulAVR irgendwie mit der compilierten Datei (.elf ?) starten und
anschliessend dem gdb (irgendwie) sagen, dass das das Zielsystem ist.
Richtig?

Warum der GDB nichtmal ein `list' ausführt, ohne ein backend zu
besitzen, kann ich jetzt nur mutmaßen.  Von der Fehlermeldung her,
die Du beschrieben hast, arbeitet er offensichtlich mit den
Adressen des Targets als zentralem Aufhänger und will sich von
diesen aus dann die Zeilennummern der Quelldatei erschließen.  Wenn
kein Target dran hängt, kann er das dann nicht mehr.

SimulAVR läßt sich meines Wissens bislang nur mit einem reinen
Binärimage starten, nicht mit einer ELF-Datei.  (AVaRICE kann
mittlerweile auch die ELF-Objekte direkt lesen.)  Das Image erzeugst
Du mit avr-objcopy, ganz ähnlich wie die Erzeugung einer iHex-Datei,
nur eben mit -O binary statt -O ihex.  Außerdem mußt Du ihm noch den
CPU-Typ des zu simulierenden Controllers auf den Weg geben.  Ein
typischer Aufruf für mich sieht ungefähr so aus:

simulavr -d atmega128 -g filename.bin

oder auch

simulavr -d atmega128 -g -P simulavr-disp filename.bin

Die zweite Form startet noch ein xterm mit der Ausgabe des
Prozessorstatus (Flags, CPU-Register, Ports, RAM-Inhalt), ich
habe keine Ahnung, ob und wie das in der Windows-Portierung auch
implementiert und benutzbar ist.

Im GDB verbindet man sich dann mittels

target remote :1212

mit dem laufenden simulavr-Prozeß.  Port 1212 ist der Default, wenn
keine -p Option angegeben worden ist.  Der Hostname vor dem
Doppelpunkt darf leer bleiben, das ist gewissermaßen die Kurzform,
um `this host' zu sagen.  (Genauer gesagt übersetzt es sich in die
besondere IP-Adresse 0.0.0.0, symbolisch IPADDR_ANY genannt, diese
wiederum erreicht den eigenen Host auf dem kürzesten Wege, ist also
in aller Regel äquivalent zu 127.0.0.1.)

Wichtig ist danach, daß Du kein `run'-Kommando geben kannst im GDB,
sondern mit `continue' weitermachen mußt, da das `target' Kommando
gewissermaßen den laufenden Simulator ,,unterbrochen'' hat.  Vorher
wirst Du natürlich irgendwo einen breakpoint setzen wollen...

Ein `kill' beendet die laufende TCP-Verbindung.  SimulAVR startet
sich in diesem Falle automatisch neu und wartet auf eine neue
Verbindung (im Gegensatz übrigens zu AVaRICE, das sich dabei
beendet).  Falls Du das ELF-File modifiziert hast, dann folgende
Reihenfolge einhalten:

(gdb) kill

Beenden der laufenden Simulation.

(gdb) file myfile.elf

Damit wird der Inhalt und die Symboltabelle aus dem neu gebauten
ELF-File myfile.elf in den GDB geladen.

(gdb) target remote :1212

Herstellen der neuen Verbindung zu SimulAVR.

(gdb) load

Damit wird das Dateiabbild, mit dem SimulAVR arbeitet, von dem, mit
dem der GDB arbeitet, neu überladen.  (Man kann SimulAVR auch ganz
ohne Dateinamen starten, dann muß man auch vor der ersten
Simulation schon ein `load' eingeben.)

SimulAVR bietet nur rudimentären IO-Support.  Damit ist die Auswahl
der CPU auch nicht allzu kritisch, Du solltest eben nur eine nehmen,
die mit Deiner vom Umfang des RAM und ROM übereinstimmt.

Vielen Dank für die sehr ausführliche Hilfe. Klingt erstmal alles ganz
logisch.  :o)

Ich werd's mal ausprobieren.