Fehler bei Benutzung von gdb

[Joerg (Gast)]

Hi,

ich verwende die neueste Version von WinAVR (Sept. 03).
Als erstes habe ich das unter 'examples' vorhandene demo.c
kompiliert, um zu sehen, ob alles funktioniert.
Kompilieren hat auch funktioniert, aber ich kann das Ergebnis einfach
nicht dem gdb unterjubeln.  :o(
Ich starte gdb, lade anschliessend die Datei zum Debuggen und will mir
als Erstes mit list den Inhalt der Datei ansehen. Dabei erhalte ich
folgende Meldung:

------------
c:\WinAVR\examples\demo>avr-gdb
GNU gdb 5.3.91
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-cygwin --target=avr".
(gdb) file demo.elf
Reading symbols from demo.elf...done.
(gdb) list
Cannot access memory at address 0x12e
(gdb)
------------

Die Datei demo.c wurde mit -o0 -g kompiliert. Damit sollten eigentlich
die notwendigen Infos in demo.elf enthalten sein...

Wo liegt der Fehler? Wie kann ich das Programm mit gdb debuggen?

Danke
Jörg

P.S. Falls Jörg Wunsch diesen Thread mitliest:
Standardmäßig wird demo.c mit -o2 kompiliert. Ein Kompilieren mit -o0
bringt einen Fehler. Es wird die Benutzung der Funktion
'timer_int_en()' (oder so ähnlich, ich schreibe aus dem Gedächtnis)
moniert. Erst nach dem Auskommentieren (dann ist sicher die Funktion
des Programmes nicht gewährleistet, aber zum Test des Kompilers...)
wird demo.c klaglos kompiliert.

[Joerg Wunsch (Gast)]

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.

[Joerg (Gast)]

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?

[Joerg Wunsch (Gast)]

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.

[Joerg (Gast)]

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

Ich werd's mal ausprobieren.