Hallo,
ich schreibe gerade ein Assembler Programm und benutze dabei den
avr-gcc als Plug-Inn im AVR-Studio. Dabei würde ich auch gern bleiben,
da ich später gern unter C aufrufen möchte.
Leider kann ich nicht Schrittweise Debuggen. (Abgesehen von der
Disassembler Funktion). In der AVR-gcc mailinglist habe ich dann diesen
vielversprechenden Post gefunden:
http://lists.gnu.org/archive/html/avr-gcc-list/2004-01/msg00074.html
Schritt 1)-4) habe ich mal großzügig übersprungen und lediglich die
codezeilen eingefügt. Ich denke mal genau darin liegt auch das Problem,
es funktioniert nämlich nicht.
Lassen sich die ersten 4 Schritte dem AVR-Studio irgendwie beibringen?
Gruß
Leif
Das geht leider nur so, wie dort beschrieben, damit auch nicht
mit dem ELF/DWARF-2-Objektformat, das ansonsten derzeit benutzt
wird (es ist viel moderner als das altmodische COFF).
Irgendwie will es nicht so wie ich es will...
Nochmal das Konzept, nur um missverständnisse auszuräumen:
1) alle .s und .c händisch kompilieren
2) alle enstandenen .o zusammenlinken
3) das enstandene .elf in .cof umwandeln
4) im AVR Studio "irgendwie" das .cof im dem project ausführen (ohne
das das studio nochmals compiliert) in dem sich der zugehörige
quellcode befindet.
Wenn ich die Dokumentation der GNU-Tools richtig verstandne habe,
müsste das .cof noch alle informationen enthalten um Schrittweises
debuggen zu ermöglichen.
Wenn das so korrekt ist, dann habe ich keine Ahnung, wie ich Schritt 4
ausführen soll.
> 1) alle .s und .c ...
.S bitte -- für den Compiler ist es wichtig, dass auf der
Kommandozeile ein großes S steht (auch wenn er unter Win32
damit die gleiche Datei finden würde wie mit einem kleinen s).
> ...keine Ahnung, wie ich Schritt 4> ausführen soll.
Ich bin kein AVR-Studio-Experte (ich habe kein Windows und
finde AVR Studio eher grässlich zu benutzen), aber meines
Erachtens legst du einfach mal kein Projekt oder sowas an,
sondern öffnest die COFF-Datei ganz normal mit File -> Open.
> .S bitte -- für den Compiler ist es wichtig, dass auf der> Kommandozeile ein großes S steht (auch wenn er unter Win32> damit die gleiche Datei finden würde wie mit einem kleinen s).
Jo, sind auch so benannt.
> Ich bin kein AVR-Studio-Experte (ich habe kein Windows und> finde AVR Studio eher grässlich zu benutzen), aber meines> Erachtens legst du einfach mal kein Projekt oder sowas an,> sondern öffnest die COFF-Datei ganz normal mit File -> Open.
Hmm... Da drängen sich bei mir fragen auf:
- Wie soll mir das Studio wärend der Ausführung meinen Quellcode
zeigen, wenn ich ihm nur das .cof gebe?
- Wenn ich nur das .cof im studio ausführe, dann bekomme ich die
gleiche disassembler ansicht, die ich auch bekomme wenn ich mein
ursprümngliches GCC project mit den .c und .S datein automatisch
compilieren lasse. Sobald ich im C-programm mit F11 (step into) in die
assembler funktion hineinspringe, öffnet sich das disassembler fenster.
Nur das ich so zumindest den in c geschrieben teil debuggen kann.
Welchen vorteil bringt mir dann das erzeugen des .cof?
OK, ich bin jetzt ein wenig weiter aber noch nicht am Ziel.
Das .cof, wenn es richtig erzeugt wurde, enthält alles nötige zum
debuggen, sogar den ursprünglichen Quellcode.
Jedoch will es sich nicht so recht erzeugen lassen.
Ich habe zum testen ein kleines Programm geschrieben:
.stabs "",100,0,0,
.stabs "swapit.S",100,0,0,main
.global main
.func main
main:
lds 18, 0xAB
lds 19, 0xCD
eor 18, 19
eor 19, 18
eor 18, 19
ende: rjmp ende
.endfunc
compilieren erfolgte ohne fehlermeldung mit:
avr-gcc -mmcu=atmega128 -o swapit.o swapit.S
linken klappt nicht:
avr-gcc -g -o swapit.elf swapit.o
führt zu folgenden Fehlermeldungen:
C:\Leif\AVR Workspave\GCC Compiler\testassembler>avr-gcc -g -o
swapit.elf swapit.o
swapit.o: In function `__bad_interrupt':
../../../../../avr-libc-1.4.4/crt1/gcrt1.S:123: multiple definition of
`__bad_interrupt'
C:/WinAVR/bin/../lib/gcc/avr/3.4.6/../../../../avr/lib/crts8515.o:../../
../../..
/avr-libc-1.4.4/crt1/gcrt1.S:51: first defined here
swapit.o: In function `__vectors':
../../../../../avr-libc-1.4.4/crt1/gcrt1.S:51: multiple definition of
`__vectors'
C:/WinAVR/bin/../lib/gcc/avr/3.4.6/../../../../avr/lib/crts8515.o:../../
../../..
/avr-libc-1.4.4/crt1/gcrt1.S:51: first defined here
Ich bin ein wenig ratlos.
> compilieren erfolgte ohne fehlermeldung mit:> avr-gcc -mmcu=atmega128 -o swapit.o swapit.S
Das compiliert nicht nur, sondern linkt zugleich mit. Daher
ist in der Ausgabe bereits das Laufzeitsystem eingebunden.
Bitte füge die Option -c mit ein.
Vielen Dank erstmal soweit!
Ich habe die option -c eingefügt. Ich vermute alternative hätte ich
auch einfach avr-as statt avr-gcc aufrufen können.
Compilieren und Linken funtioniert nun soweit ganz gut.
comilieren:
avr-gcc -c -mmcu=atmega128 -o swapit.o swapit.S
linken:
avr-gcc -g -o swapit.elf swapit.o
Die umwandlung in das COFF Format wirft 3 Warunungen aus:
avr-objcopy -O coff-ext-avr --debugging swapit.elf swapit.cof
Warning: file C:/DOCUME~1/EWEDDI~1/LOCALS~1/Temp/ccQNdaaa.s not found
in symboltable, ignoring
Warning: ignoring function __vectors() outside any compilation unit
Warning: ignoring function __bad_interrupt() outside any compilation
unit
Das .cof welches dabei erzeugt erscheint mit mit 3 kb etwas klein
gegenüber dem 4 kb großen .elf.
Es lässt sich zwar im AVRStudio öffnen, jedoch meldet dies:
Coordinator: The object file does not contain source code information.
Eine Datei ccQNdaaa.s gibt es nicht, nicht mal das zugehörige
verzeichnis.
> Ich vermute alternative hätte ich auch einfach avr-as statt avr-gcc> aufrufen können.
Der Unterschied ist, dass der Compiler vorher noch den Präprozessor
aufruft. Den brauchst du für das #include <avr/io.h>.
> avr-gcc -c -mmcu=atmega128 -o swapit.o swapit.S
Da fehlt jetzt aber das -g ...
> Die umwandlung in das COFF Format wirft 3 Warunungen aus:
OK, ignorier' sie.
> Das .cof welches dabei erzeugt erscheint mit mit 3 kb etwas klein> gegenüber dem 4 kb großen .elf.
Das ist OK. Die Größe dieser Dateien sagt nicht viel. Die Strukturen
sind komplett anders, bei COFF wurde mit jedem Byte gespart (mit dem
Erfolg, dass es völlig vernagelt und nicht mehr erweiterbar war, z. B.
ist es aussichtslos, C++-Debug-Infos unterzubringen). Bei ELF waren
die Festplatten dann größer, da war man großzügiger geworden.
> Es lässt sich zwar im AVRStudio öffnen, jedoch meldet dies:> Coordinator: The object file does not contain source code
information.
Klar, hast du ihm ja auch nicht mitgegeben.
> Eine Datei ccQNdaaa.s gibt es nicht, nicht mal das zugehörige> verzeichnis.
Das ist der Name einer temporären Datei, die beim normalen Compilieren
der avr-libc eingetragen worden ist (vermutlich im gcrt1.S). Offenbar
hat Eric Weddington irgendeine Datei nicht vorm Ausliefern mit
avr-strip -g behandelt, sodass sie die Debug-Infos noch enthält.
ich muss nochmal nachfragen - sorry
mit dem -g sieht es nun wie folgt aus:
compilieren:
avr-gcc -g -c -mmcu=atmega128 -o swapit.o swapit.S
linken:
avr-gcc -g -o swapit.elf swapit.o
umwandlung in COFF:
avr-objcopy -O coff-ext-avr --debugging swapit.elf swapit.cof
(mit den 3 Warnungen)
AVRStudio meldet weiterhin:
Coordinator: The object file does not contain source code information.
Das ist nun allerdings seltsam.
avr-objdump -g müsste sowohl auf dem ELF- als auch auf dem
COFF-File eine einigermaßen sinnvolle Ausgabe bringen. Ist
dem so?
Ah, nee, warte mal: du musst ja dem Assembler sagen, dass
er die Debuginformation generiert, nicht dem Compiler:
-Wa,--gstabs (kann sein, dass -Wa,-g auch geht).
Die debugg infos von dem .elf sehen nach irgendwas aus, zumindest der
Teil
typedef void void;
void main ()
{ /* 0x2a */
/* file swapit.S line 7 addr 0x2a */
/* file swapit.S line 8 addr 0x2c */
/* file swapit.S line 9 addr 0x30 */
/* file swapit.S line 10 addr 0x34 */
/* file swapit.S line 11 addr 0x36 */
/* file swapit.S line 12 addr 0x38 */
/* file swapit.S line 13 addr 0x3a */
} /* 0x3c */
swapit.S:
Die debugg information von dem .cof würde ich als nicht vorhanden
interpretieren.
avr-objdump -g swapit.cof
swapit.cof: file format coff-ext-avr
debug_name_type: no current file
Bei keinem von beiden lässt mit dem Studio debuggen.
Hat noch Jemand eine Idee?
Bei mir kam nur Schwachsinn raus, bis ich aus deinem
.stabs "",100,0,0,
.stabs "swapit.S",100,0,0,main
mal ein
.stabs "",100,0,0,main
.stabs "swapit.S",100,0,0,main
gemacht habe.
Ich bin übrigens nie ganz draus schlau geworden, wofür der Name
des Symbols, das man bei .stabs ... 100 angeben muss, genau ist.
Mein Rat: nimm das erste Symbol, das du innerhalb deiner
Assemblerdatei finden kannst.
Das Ganze ist nur eine Krücke, damit der COFF-Konverter, der bis
dahin nur den Namen der temporären Assembler-Datei gesehen hat,
die der GCC nach dem Präprozessor angelegt hat, noch irgendwie
den Namen der ursprünglichen Assemblerdatei in die COFF-Symbole
mit aufnehmen kann.
Mit dem fehlenden Symbol in der ersten Zeile hat bei meinem
einfachen Test das avr-objdump -g dann irgendwas von corrupted
stabs erzählt, das hat mich stutzig gemacht.
es ist wie verhext..
Nachdem eine einzelne Assemblerfunktion sich nun debuggen lässt,
ist mein nächster Schritt nun ein mini C-Prgramm, welches meine
Assemblerfunktion aufruft.
mein C-Programm:
#include <avr/io.h>
volatile uint8_t swap1;
volatile uint8_t swap2;
int main (void){
extern void swapit(volatile uint8_t, volatile uint8_t);
swap1 = 10;
swap2 = 40;
swapit(swap1, swap2);
return(0);
}
mein Assembler Programm:
.stabs "",100,0,0,swapit
.stabs "swapit.S",100,0,0,swapit
; constants
.extern swap1
.extern swap2
.global swapit
.func swapit
swapit:
CLI
lds 18, 0xAB
lds 19, 0xCD
eor 18, 19
eor 19, 18
eor 18, 19
SEI
.endfunc
Compilieren und Linken läuft problemlos.
compilieren:
avr-gcc -Wa,--gstabs -c -mmcu=atmega128 -o givemeswap.o givemeswap.c
avr-gcc -Wa,--gstabs -c -mmcu=atmega128 -o swapit.o swapit.S
linken:
avr-gcc -g -o givemeswap.elf givemeswap.o swapit.o
convertieren wirft einige Warnungen raus:
avr-objcopy -O coff-ext-avr --debugging givemeswap.elf givemeswap.cof
Das Studio bemängelt keine Fehlenden Debuginformationen beim öffnen des
.cof - soweit so gut!
Dafür bekomme ich folgendes:
"This project appears to have been moved. Please browse to the present
location for files originally found at C:\avr-libc-1.4.4\crt1\"
Dazu fallen mir 2 Dinge ein:
1)Ich habe wie letzes mal auch direkt das .cof geöffnet und das Studio
hat wie zuvor auch selbsständig ein Projekt dazu angelegt.
2)Einen Pfad beginnend mit C:\avr-libc-1.4.4\... gibt es nicht und
gab es nicht
Vorgeschlagener Pfad ist, der zuletzgeöffnete, dort wo das .cof und
auch .c .S liegen. Wählt man diesen, akzeptiert das Studio es.
Es öffnet den Quelltext der .S und beginnt zu debuggen -
aber vom C-Quellcode keine Spur!
Die Warunungen beim Umwandeln sehen nicht viel anders aus als sonst.
Ein obj-dump gibt ähnliche ergebnisse wie zuvor.
Poste ich auch gern alles dazu wenn bedarf besteht.
Anregungen und Vorschläge sehr willkommen.
> avr-gcc -Wa,--gstabs -c -mmcu=atmega128 -o givemeswap.o givemeswap.c
Umm, nö, du willst doch den C-Code nicht assemblerzeilenweise
debuggen. ;-) Also solltest du auch nicht dem Assembler sagen,
dass er die Debuginformationen (genauer: Zeilennummerninformationen)
liefert (-Wa,--gstabs), sondern dem Compiler, dass er diese
liefert (-gstabs, ohne dem -Wa).
Die Rückfrage nach dem Pfadnamen hängt damit zusammen, dass der
von dir angegebene Name (swapit.S) keine Pfadinformation hat und
offenbar nicht in dem Verzeichnis lag, in dem AVR Studio danach
gesucht hat. Aber da man den ja mittlerweile interaktiv
eingeben darf, ist das kein Thema. Dumm ist nur, dass die Abfrage
nicht nochmal kommt, wenn du dich da irgendwie mal geirrt hast,
musst du das einfach im XML ändern (was anderes sind die Projekt-
dateien vom AVR Studio zum Glück nicht). Wenn du dort die
entsprechende Zeile löschst, kommt beim nächsten Mal die Abfrage
neu. Wenn man die Antwort für zwei Dutzend Dateien eingeben
soll, ist das Editieren des XML wahrscheinlich auch viel schneller
als das Klickibunti. ;-)
> Einen Pfad beginnend mit C:\avr-libc-1.4.4\... gibt es nicht und> gab es nicht
Doch, bei Eric Weddington auf dem Rechner. ;-) Das kommt vom
crtXXX.o-File, dem C runtime startup. Das ist das File, von dem
Eric die Debuginformationen offenbar vor der Auslieferung nicht
entfernt hast, das ist auch das, was dir das:
Warning: file C:/DOCUME~1/EWEDDI~1/LOCALS~1/Temp/ccQNdaaa.s not found
in symboltable, ignoring
beschert.
-Wa ist raus, macht auch Sinn ;-)
jedoch:
avr-gcc -c --gstabs -mmcu=atmega128 -o givemeswap.o givemeswap.c
cc1.exe: error: unrecognized command line option "-fgstabs"
Woher kommt das f ?
Die help sagt:
"Options starting with -g, -f, -m, -O, -W, or --param are
automatically
passed on to the various sub-processes invoked by avr-gcc. In order to
pass other options on to these processes the -W<letter> options must be
used."
Ja super. Vielen Dank!
Was ist eigentlich der Grund dafür, daß es im ELF Format nicht
funktioniert? Eigentlich enthält es ja alle nötigen Informationen.
Liegt das nur am AVRStudio?
> Was ist eigentlich der Grund dafür, daß es im ELF Format nicht> funktioniert?
Mit ELF hat das nichts zu tun, die stabs werden ja auch im ELF-File
übertragen. ;-)
Es hat was mit DWARF-2 zu tun und damit, dass selbige leider in
allen GNU binutils irgendwie ,,neben der Spur'' behandelt worden
sind. Für den AVR hat das Zeug keiner angefasst, so funktioniert
alles das, was mit DWARF-2 funktioniert, nur zufällig. Zufällig
funktioniert dabei die Generierung der nötigen DWARF-2 line
number information im Assembler leider nicht (obwohl sie für
andere Targets wie i386 funktioniert). Es gibt im Moment auch
niemanden, der freiwillig "hier!" gerufen hätte, sich das mal
anzusehen...
