Assembler Schrittweise Debuggen (AVR-gcc)

[Leif U. (boing)]

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

[Jörg W. (dl8dtl) (Moderator)]

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).

[Leif U. (boing)]

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.

[Jörg W. (dl8dtl) (Moderator)]

> 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.

[Leif U. (boing)]

> .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?

[Leif U. (boing)]

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.

[Jörg W. (dl8dtl) (Moderator)]

> 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.

[Leif U. (boing)]

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.

[Jörg W. (dl8dtl) (Moderator)]

> 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.

[Leif U. (boing)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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).

[Leif U. (boing)]

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

[Leif U. (boing)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Leif U. (boing)]

Jetzt klappt es.
Da sag' ich mal riesen Dank!!!!

[Jörg W. (dl8dtl) (Moderator)]

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.

[Leif U. (boing)]

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.

[Jörg W. (dl8dtl) (Moderator)]

> 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.

[Leif U. (boing)]

-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."

[Jörg W. (dl8dtl) (Moderator)]

-gstabs statt --gstabs.  Ist dumm, der Compiler will sie mit
einem Minus, der Assembler aber mit zwei Minuszeichen.

[Leif U. (boing)]

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?

[Jörg W. (dl8dtl) (Moderator)]

> 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...