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

[E. Weddington]

Ok, I don't think Babel Fish is gonna handle this one. :-)

Was this a posting mistake?

Eric


On 27 Mar 2003 at 20:06, Markus Assfalg wrote:

> 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
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list