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).
compilieren: avr-gcc -Wa,--gstabs -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 (Diesmal mit 4 Warnungen) 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 Warning: file C:\DOKUME~1\Leif\LOKALE~1\Temp/ccsVaaaa.s not found in symboltable, ignoring Warning: ignoring function main() outside any compilation unit Ich bin mir nicht sicher wie eine sinnvolle Ausgabe von avr-objdump -g aussieht, aber ich poste die ausgabe einfach mal: auf .cof: avr-objdump -g swapit.cof swapit.cof: file format coff-ext-avr debug_name_type: no current file auf .elf: avr-objdump -g swapit.elf swapit.elf: file format elf32-avr C:/DOCUME~1/EWEDDI~1/LOCALS~1/Temp/ccQNdaaa.s: typedef void void; void __vectors () { /* 0x0 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 51 addr 0x0 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 52 addr 0x2 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 53 addr 0x4 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 54 addr 0x6 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 55 addr 0x8 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 56 addr 0xa */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 57 addr 0xc */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 58 addr 0xe */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 59 addr 0x10 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 60 addr 0x12 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 61 addr 0x14 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 62 addr 0x16 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 63 addr 0x18 */ } /* 0x1a */ ../../../../../avr-libc-1.4.4/crt1/gcrt1.S: /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 64 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 65 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 66 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 67 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 68 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 69 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 70 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 71 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 72 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 73 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 74 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 75 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 76 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 77 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 78 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 79 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 80 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 81 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 82 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 83 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 84 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 85 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 86 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 87 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 88 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 89 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 90 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 91 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 92 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 93 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 94 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 95 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 96 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 97 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 98 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 99 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 100 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 101 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 102 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 103 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 104 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 105 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 106 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 107 addr 0x1a */ void __bad_interrupt () { /* 0x28 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 123 addr 0x28 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 144 addr 0x1a */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 145 addr 0x1c */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 146 addr 0x1e */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 148 addr 0x20 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 149 addr 0x22 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 151 addr 0x24 */ /* file ../../../../../avr-libc-1.4.4/crt1/gcrt1.S line 199 addr 0x26 */ } /* 0x2a */ C:\DOKUME~1\Leif\LOKALE~1\Temp/ccsVaaaa.s: 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: Vielen Dank schonmal
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."
-gstabs statt --gstabs. Ist dumm, der Compiler will sie mit einem Minus, der Assembler aber mit zwei Minuszeichen.
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.