Re: [avr-gcc-list] .data section

[Markus Assfalg]

Hallo,

> > Ich glaube, dass das nicht einfach wird, da die Burschen ja mit IAR
> > zusammen den AVR-Core entworfen haben und IAR seine Compiler
> > verkaufen will
>
> Na ja, ein bißchen einen Draht habe ich zu denen inzwischen.
>
> > (hab mal mit dem IAR430 fuer den MSP430 gearbeitet - eine Katastrophe).
>
> COFF ist ja auch eine Katastrophe.  Der MSP430 soll wohl einfacher zu
> handhaben sein aus Compilersicht, da er einen flat address space hat.
> Wenn ich mir die Verrenkungen mit Offset 0x800000 so ansehe...

Ich meinte nicht unbedingt das Objektformat sondern den Compiler selber.
Man hat z.B. in einer Funktion ein ; vergessen und erhaelt die vielsagende
Fehlermeldung "error in function xyz".

> > Der Schluessel koennte auch beim ELF2COFF-Konverter (objtool) liegen.
>
> Der ist oberkrank.
>
> Vorgeschichte: ich habe kein Windows, will auch keins haben, bin mir
> aber nach Blick in AVRfreaks völlig darüber im Klaren, daß wir
> wenigstens derzeit (*) noch einen besseren AVR COFF Support brauchen.
> Daher habe ich mir objtool angsehen und festgestellt, daß das einfach
> das Pferd von hinten aufgezäumt ist.  Es reimplementiert einen Haufen
> Zeug (mit einem Haufen neuer hausgemachter Bugs), das woanders schon
> existiert.

Ich bin auch ein LINUX-Juenger und bin nur wegen den ELF2COFF-Konvertern
auf Windows (mit dieser Entwicklungsumgebung) gewechselt (wobei das
AVRstudio 4.x ja  ganz nett ist und ich auf dieses nicht mehr verzichten
moechte - aber man kann ja unter LINUX entwickeln und dann unter Windows
nur debuggen - VNC bzw. VMware sei dank).

> (*) Atmel hat den Unsinn von COFF auch schon ein Weilchen erkannt und
> wird über kurz oder lang zu ELF wechseln.  

Das Problem ist, dass es wahrscheinlich eher laenger als kuerzer dauert. Die 
Funktionen brauche ich aber ziemlich bald, da ich eine Entwicklung machen 
muss. Ansonsten bin ich gezwungen mir doch einen IAR fuer eine ganze Menge 
Geld zu besorgen (was taugen die anderen Compiler fuer den AVR - z.B.
CodeVision, ImageCraft ?) - nach meiner Erfahrung mit dem IAR fuer MSP430
moechte ich kein Geld fuer das Ding ausgeben (den GNU kennt man halt
schon sehr genau und kann auch seine Fehlermeldungen ziemlich genau
interpretieren).
Mir wuerde es reichen, wenn die Programme einfach in AVRstudio 4.x laufen.

> Wechseln müssen, da vor allem das COFF-Debug-Format total hirnrissig und 
> vernagelt ist.  Das kann lediglich die Dinge, die man bereits vor 15 Jahren 
> als wichtige Debug-Information gekannt hat, also praktisch nur K&R C.  
> Damit ist einfach keinerlei Support für C++ oder andere Erweiterungen drin;
> nichtmal ein long long int kann in COFF dargestellt werden.  Sie
> werden ELF vermutlich mit DWARF Debugging machen (wir benutzen derzeit
> stabs Debugging), aber das ist zumindest für gcc/IA32 inzwischen auch
> schon da, sollte also kein unendliches Problem sein.
>
> Die IMHO einzig sinnvolle Lösung heißt [avr-]objcopy.  Dem muß man die
> Formate coff-avr und coff-ext-avr (letzteres ist das neuere Format,
> das ab AVR Studio 4.07 unterstützt wird) beibringen.  Das ist gar
> nicht so schwierig (war praktisch keine 2 Stunden Arbeit), da die GNU
> binutils ohnehin schon mehr als 2 Dutzend verschiedene COFF-Formate
> unterstützen.  OK, Atmel hat von einigen Details in COFF sehr
> eigenwillige Vorstellungen, die ziemlich stark von Standard-COFF
> abweichen, die schwimmen viel zu sehr in ihrer eigenen Suppe.  Ich
> frage mich, warum sie das Ganze noch COFF nennen...

Wenn ich das richtig verstehe, hast Du "objcopy" schon "coff-ext-avr"
beigebracht und das unter LINUX. Hoert sich doch gut an ;-)
Was muss ich machen, damit ich das meinem avr-objcopy auch
beibringen kann ?

> Das einzige wirkliche Problem ist, daß die GNU binutils derzeit COFF
> debug information nur lesen, nicht aber selbst erzeugen können.  (Mit
> --debugging kann objcopy die vorhandenen Debug-Informationen aus der
> Eingabedatei in ein internes Format überführen und dann von dort
> wieder ausgeben.  Ohne --debugging werden einfach nur die sections
> kopiert, würde in unserem Falle also das stabs debugging übernommen,
> mit dem die AVR-Tools nichts anfangen können.)  Dies zu tun, daran
> arbeite ich seit einem Weilchen, und all die simpleren Dinge habe ich
> inzwischen im Griff.  Komplexe Datentypen (Zeiger auf Funktionen und
> sowas) stimmen noch nicht richtig, zumal Atmel hier auch wiedermal was
> verbogen hat.  struct members habe ich auch noch nicht fertig, die
> sind aber ohnehin nur in coff-ext-avr ab AVRSt 4.07 unterstützt.  Ich
> werde am Ende der Vollständigkeit halber wohl auch Dinge unterstützen,
> die Atmel nicht kann (enums und typedefs).

Also auf komplexe Datentypen kann ich vorerst verzichten. Man kann
sich ja, bis Besserung in Sicht ist, mit einem Speicherauszug weiterhelfen ;-)

> > Man muesste den Inhalt der .data-Sektion der .text unterjubeln.
>
> Das wiederum stelle ich mir mit objcopy eher schwierig vor.  Wenn bei
> Atmel wirklich kein Weg reinführt, daß sie vielleicht auch .data aus
> dem COFF mit laden, würde ich lieber ein separates Tool dafür
> schreiben (das natürlich auf der BFD-Bibliothek der binutils
> aufsetzt).

Wie siehst Du die Chance, dass sich bei Atmel in dieser Hinsicht etwas tut?
Und vor allem: wie sieht die Roadmap in Bezug ELF-Unterstuetzung etwa aus?
Falls die ELF-Unterstuetzung absehbar ist, waeren die Muehen fuer eine 
Loesung fuer das Erzeugen des Atmel-coff's ja fast fuer die Katz. 
Da muesste man bei den Herren bei Atmel mal anklopfen, damit die 
ELF-Unterstuetzung an Prioritaet dazugewinnt. Waere fuer Atmel ja ein 
richtig gutes Verkaufsargument, wenn man eine komplette Entwicklungsumgebung
_gratis_ anbieten kann (Fujitsu macht das ja schon vor). Fuer den MSP430
gibt es ja auch schon einen Port fuer den GCC. Das sind alles 
Konkurenten von Atmel (Fujitsi 16bit zum Preis eines AVR-8bit -
wer da dem Fujitsu nicht genau unter die Haube blickt merkt nicht,
dass die Architektur nicht so das Gelbe vom Ei ist und ein AVR in den 
meisten faellen schneller ist).

> > Wo kann man die Quellen von objtool
> > bekommen ?
>
> Irgendwo bei AVRfreaks.  Ich kann sie Dir auch mailen, wenn Du Dir das
> unbedingt antun willst.

Nach deiner Beschreibung bin ich nun von "objtool" noch weniger ueberzeugt
als ich das vorher auch schon war.

Falls ich dir irgendwie unter die Arme greifen kann ....

Viele Gruesse
Markus