www.mikrocontroller.net

Forum: Compiler & IDEs Frage zu WINAVR-20071221


Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Komisch, unter Linux tut avr-objdump -S (Version 2.18) das, was es
soll. Voraussetzung ist natürlich, dass das Programm mit Debuginfos
(-g) kompiliert wurde.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: roboterheld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht es denn nun in dem neuem winavr-c von dezember 2007?
mfg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Christoph Resele (resele)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph Resele (resele)
Datum:

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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sollte ein
#if defined (O_BINARY)
allgemein "gültig" sein. Oder spricht was dagegen?

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.