Ich hab ihn jetzt mal installiert.

Der Code bei meiner Anwendung ist wieder kleiner geworden, sogar weniger
als beim WINAVR-20060517:

4.1.1
   text    data     bss     dec     hex filename
    404      18       8     430     1ae test.out

4.1.2
   text    data     bss     dec     hex filename
    420      18       8     446     1be test.out

4.2.2
   text    data     bss     dec     hex filename
    380      18       8     406     196 test.out

Leider werden nun aber keine Quelltextzeilen mehr im Listing angezeigt.

Weiß jemand vielleicht, ob man das irgendwie wieder hinkriegt?


Peter

Ist wohl ein Fehler in den neuen binutils (objdump und/oder bdf). Wurde
bei avrfreaks schon angesprochen und ist unter
http://sourceforge.net/tracker/index.php?func=deta...
als Fehler gelistet. Abhilfe habe ich leider keine. Bin bei meiner
"Werkzeugsammlung" für ARM auch darauf gestossen, habe auf Anhieb keine
Lösung gefunden und nutze daher weiter binutils 2.17.

Hast du's auch mal mit -gdwarf-2 probiert?  Vielleicht liegt da ja
der Pfeffer im Hasen.

Jörg Wunsch wrote:
> Hast du's auch mal mit -gdwarf-2 probiert?  Vielleicht liegt da ja
> der Pfeffer im Hasen.

Ob -g oder -gdwarf-2 macht keinen Unterschied.
D.h. die alten WINAVRs gehen, der neue nicht.

Hier mal meine Kommandozeile:

avr-gcc.exe -xc -Os -mmcu=attiny84 -Wall -gdwarf-2 -o test.out *.c
avr-objdump.exe -h -S test.out >test.lst

Peter

Peter Dannegger wrote:

> Ob -g oder -gdwarf-2 macht keinen Unterschied.

Sorry, die Frage bezog sich auf yalu.  Je nach Lieferant der Toolchain
benutzen Unix/Linux-Konfigurationen als default für -g den Wert -gstabs
(da der AVR-GDB nicht sinnvoll mit DWARF-2 umgehen kann), WinAVR aber
benutzt -gdwarf-2 (weil das das Format ist, mit dem AVR Studio als
einziges umgehen kann).  Kann also sein, dass die aktuellen binutils
ein Problem haben, die DWARF-2-Debuginformation in das Disassembler-
Listing zurückzumischen, während sie kein Problem mit stabs haben.
Keine Ahnung warum, andererseits ist unser DWARF-2-Support in den
GNU-Tools bislang reiner Zufall und lediglich ein Abfallprodukt davon,
dass die GCC mainstream targets (allen voran also i386) auf DWARF-2
als default gewechselt haben.  Es gibt derzeit niemanden, der das
speziell für den AVR aktiv pflegen würde.

Also wenn ich mit dem neuen AVR-GCC compiliere und mit dem alten
AVR-OBJDUMP das Listing erzeuge, dann gehts.

Ich habe dazu die PATH-Variable zwischen den beiden Zeilen umgesetzt.

Oder könnte ich auch einfach das neue AVR-OBJDUMP mit dem alten
überbraten?


Peter

Peter Dannegger wrote:

> Also wenn ich mit dem neuen AVR-GCC compiliere und mit dem alten
> AVR-OBJDUMP das Listing erzeuge, dann gehts.

Schon klar.  avr-objdump ist Teil der binutils, und da gibt's in
Version 2.18 offenbar ein Problem.

> Oder könnte ich auch einfach das neue AVR-OBJDUMP mit dem alten
> überbraten?

Da objdump ein reines Analysetool für menschliche Benutzung ist,
wird das sicher gehen.  Die Tools selbst brauchen das nicht.
Kannst das andere ja in avr-objdump-2.18.exe umbenennen.

roboterheld wrote:

> geht es denn nun in dem neuem winavr-c von dezember 2007?

"es" geht.  Fragt sich nur, was "es" ist.  Worauf beziehst du dich
denn überhaupt mit deiner Frage?  Hast du dir den Rest des Threads
durchgelesen und verstanden, oder wolltest du nur "AOL" sagen?

Ein Workaround ist die Option -l für avr-objdump.
Es werden dann zwar nur die Zeilennummern des Sourcecodes angezeigt,
aber das ist besser als nichts ;-)

"No C-Sourcecode in ASM-Listing" Workaround von DosMan
http://www.avrfreaks.net/index.php?name=PNphpBB2&f...
(Für Download ggf. kostenlos registrieren)

Im avrfreaks gcc-forum findet man auch noch ein anderes "Workaround":
Ein Nutzer berichtet, dass objdump aus WinAVR 12/07 wie gewohnt mit -S
mixed source-asm ausgibt, wenn die Quellcodedateien
"Unix-Zeilenendungen" haben. Testweise kann man also mit dos2unix oder
flip die Quellcodedateien umwandeln. (Auch wenn es funktioniert, keine
schicke Lösung.) Programmers Notepad und AVR-Studio interpretieren auch
"Unix-Zeilenendungen", der simple Editor/Notepad aus dem WinXP/2000
Lieferumfang allerdings nicht.

Danke, das hat geholfen!
Die Carriage-Returns bringen avr-objdump offensichtlich durcheinander...

Nun denn, der Sache mal etwas auf den Grund gegangen (war ein wenig
Sucherei). Mit den binutils 2.18 wurde eine neue Methode eingeführt, um
die Quellcodedateien innerhalb objdump einzulesen. Es wird dazu eine Art
Cache genutzt. Nun ist es so, dass beim Einlesen der Quellcodedateien im
unter mingw compiliertem objdump mittels read() wohl schon intern die
Zeilenendungen von "\r\n" auf "\n" konvertiert werden. Damit schlägt
eine Prüfung in objdump fehl, da die vom Dateisystem angefragte
Dateigröße nicht mit der Anzahl der Bytes übereinstimmt, die von read
gelesen werden. Die Differenz beträgt exakt die Anzahl der Zeilen, da
pro Zeile ein Byte (das für \r) fehlt. Damit erklärt sich auch, warum es
bei Dateien mit Unix-Dateiendung keine Probleme gibt. Abhilfe: Datei
unter mingw im binary-mode öffnen (unter "unixoiden" Systemen gibt es
wohl keinen Unterschied). Das folgende Patch habe ich erfolgreich für
das build-target arm-eabi und mingw/msys getestet, sollte aber
universell für alle targets sein. Dennoch ohne Gewähr.

diff -Nbaur binutils-2.18.50/binutils/objdump.c binutils-2.18.50-mod/binutils/objdump.c
--- binutils-2.18.50/binutils/objdump.c Thu Feb  7 16:04:47 2008
+++ binutils-2.18.50-mod/binutils/objdump.c     Thu Feb  7 16:02:11 2008
@@ -964,7 +964,12 @@
 #endif
   const char *map;
   struct stat st;
+  
+#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN32__
+  int fd = open (fn, O_RDONLY | O_BINARY);
+#else
   int fd = open (fn, O_RDONLY);
+#endif
 
   if (fd < 0)
     return NULL;

Auf der Basis kann sicher jemand ein "binary-patch" für das objdump im
aktuelle WinAVR erstellen (sollte nur ein Byte zu ändern sein).

Eintragung im avrfreaks Forum-Thread, im WinAVR Bugtracker und im
binutils.exe bugzilla in Kürze.

Martin Thomas
(der froh ist, das endlich gefunden zu haben. War der "Showstopper" für
binutils 2.18 in WinARM)

Ich kenne mich zu wenig mit den Besonderheiten verschiedener
Unix-Systeme aus und habe die Fallunterscheidung daher so implementiert,
dass sie nur für mingw greifen sollte und für alle anderen Systeme
"Bestandsschutz" gilt. Ist sichergestellt, dass O_BINARY "überall" per
#define festgelegt wird oder kann es auf anderen Systemen auch per
"(static) const int" definiert sein?
Wie auch immer, ich habe Eric Weddington gebeten, das Patch in den
binutils bugtracker einzutragen (habe selbst kein Account dort und
wollte nur dafür keines anlegen). Nehme an, die binutils
Maintainer/Reviewer kennen sich mit anderen Systemen aus und werden
gegebenenfalls modifizieren bevor die Änderung aufgenommen wird.

Martin Thomas

Werner Bs Vorschlag aufgegriffen und ein wenig durch den bintuils-code
gestöbert. Man findet an ein paar Stelle O_BINARY, Methode übernommen,
Patch modifiziert:

diff -Nbaur binutils-2.18.50_org/binutils/objdump.c binutils-2.18.50/binutils/objdump.c
--- binutils-2.18.50_org/binutils/objdump.c     Thu Feb  7 16:04:47 2008
+++ binutils-2.18.50/binutils/objdump.c Sat Feb  9 14:28:19 2008
@@ -70,6 +70,14 @@
 
 #include <sys/stat.h>
 
+#ifndef O_BINARY
+#ifdef _O_BINARY
+#define O_BINARY _O_BINARY
+#else
+#define O_BINARY 0
+#endif
+#endif
+
 /* Internal headers for the ELF .stab-dump code - sorry.  */
 #define        BYTES_IN_WORD   32
 #include "aout/aout64.h"
@@ -964,7 +972,8 @@
 #endif
   const char *map;
   struct stat st;
-  int fd = open (fn, O_RDONLY); 
+  int fd = open (fn, O_RDONLY | O_BINARY);
 
   if (fd < 0)
     return NULL;

(Googlefutter: objdump -S objdump --source binutils 2.18 intermix
source)

Martin Thomas