www.mikrocontroller.net

Forum: Compiler & IDEs ELF -> (EXT)COFF für VMLab; avr-objcopy Problem bei statischen Variablen im Function Scope


Autor: Martin Freund (martinf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte gern mein PWM-Programm mit VMLab mit Debuginformationen 
simulieren, erhalte aber folgende Fehlermeldung:
.
.
Index = 49  .ef  T_NULL  C_FCN  023C  
Index = 51  s_uiCommonCounter  T_UINT  C_STAT  800062  P
(!) Static variable address beyond the RAM limit: s_uiCommonCounter -> :0x800062
Index = 52  g_eState  T_CHAR  C_STAT  0060  P
.
.
COFF file contains inconsistencies or unsupported features. Debug info could be wrong or incomplete.

Ohne COFF Datei funktioniert alles (abgesehen von den fehlenden 
Debuginfos).

Der Fehler tritt auch beim Extended COFF auf.

Eigentlich dürfte diese Meldung überhaupt nicht kommen, da ja 
avr-objcopy wegen dem Parameter '--change-section-address .bss-0x800000' 
alle nicht initialisierten Variablen neu lokatiert werden. Diese werden 
um 0x800000 Bytes nach vorne verlegt.

Folgende Repro erzeugt den gleichen Fehlertyp:
int main( void)
{
    static char c = 0;
    for( ; c < 10; c++);

    return 0;
}

Warnungen beim Aufruf von "make coff" bzw. "make extcoff":
Converting to AVR Extended COFF: main.cof
avr-objcopy --debugging --change-section-address .data-0x800000 --change-section
-address .bss-0x800000 --change-section-address .noinit-0x800000 --change-sectio
n-address .eeprom-0x810000 -O coff-ext-avr main.elf main.cof
Discarding local symbol outside any compilation unit: .do_copy_data_start
Discarding local symbol outside any compilation unit: .do_copy_data_loop
Discarding local symbol outside any compilation unit: .do_clear_bss_start
Discarding local symbol outside any compilation unit: .do_clear_bss_loop
Warning: no "data" section found in output file
Warning: file C:/WINDOWS/TEMP/ccnaqnIu.s not found in symbol table, ignoring
Warning: ignoring function __vectors() outside any compilation unit
Warning: ignoring function __bad_interrupt() outside any compilation unit
avr-objcopy: --change-section-vma .eeprom+0xff7f0000 never used
avr-objcopy: --change-section-lma .eeprom+0xff7f0000 never used
avr-objcopy: --change-section-vma .noinit+0xff800000 never used
avr-objcopy: --change-section-lma .noinit+0xff800000 never used
avr-objcopy: --change-section-vma .data+0xff800000 never used
avr-objcopy: --change-section-lma .data+0xff800000 never used
Diese sind nicht weiter relevant.
(vgl. http://www.sax.de/~joerg/README.coff-avr-patch)

"avr-objdump -x test.cof" liefert u.a.
.
AUX lnno 2 size 0x0 tagndx 0
[ 15](sec -1)(fl 0x00)(ty   4)(scl   3) (nx 0) 0x00800060 i
[ 16](sec  1)(fl 0x00)(ty   0)(scl 100) (nx 1) 0x000000b2 .eb
.

Meine Vermutung ist, dass avr-objcopy den Offset einmalig falsch 
berechnet.
Nachdem ich nämlich die COFF Datei mit nem Hex-Editor nachbearbeitet 
habe funktioniert alles wunderbar. (0x00800060 wurde durch 0x00000060 
ersetzt)

Hab zu diesem Problem noch folgenden Thread gefunden:
Beitrag "Variable als static deklarieren"
Dort wird vermutet, dass es an VMlab liegt, was ich aber nach meiner 
Erkenntnis sehr bezweifle.

Anscheinend hat noch einer das selbe Problem aber auch keine Lösung:
http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1150025414

Die inakzeptable Lösung hier ist, dass man die Variable global 
deklariert:
http://translate.google.com/translate?u=electronix...

Im Binutils-Bugtracker hab ich auch nichts passendes gefunden.
Falls keiner eine Lösung hat, würde ich mir ne Art COFF-Patcher 
schreiben, der die ensprechenden Einträge in der Datei ändert.
Soweit ich weis, wird (EXT)COFF ja nicht mehr weiterentwickelt. Daher 
wird wohl das Beheben eines eventuellen Bugs im COFF Parser geringe bzw. 
keine Priorität haben.

Hat wer die Spezifikation von EXTCOFF bzw. sind die Unterschide zu COFF 
für den o.g. Parser relevant?
Für COFF hab ich sie schon gefunden: 
http://www.amelek.gda.pl/avr/old/binutils/avrcoff.pdf

-----------------------------
Verwendet wurde folgende Software, immer mit dem gleichen Ergebnis:
WinAVR v20060125, v20081205, v20090306rc1 mit dem jeweiligen 
Standard-Makefile
VMLab 3.14A
Windows XP x64 SP2, Windows XP x86 SP3 auf xVM VirtualBox

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die inakzeptable Lösung hier ist, dass man die Variable global
>deklariert:

So mach ich es.

Leider ist es meiner Erfahrung nach so, daß die Debug-Stabilität von 
VMLAB mit jeder neune WinAVR-Versiobn schlechter wird. Z.B. funktioniert 
bei mir inzwischen Einzelschritt per F6 (step over) nicht mehr, nur noch 
F7 (step into). Schade eigentlich, das ist sonst ein geniales tool.

Oliver

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Ich hab es nochmals ausprobiert.

Lokale statische Variablen bringen zwar die o.a. Fehlermeldung, lassen 
sich aber trotzdem debuggen. Lokale nicht statische Variablen dagegen 
erzeugen keine Fehlermeldung, der Debugger kennt sie aber nicht.

Oliver

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

Bewertung
0 lesenswert
nicht lesenswert
Oliver wrote:

> Lokale statische Variablen bringen zwar die o.a. Fehlermeldung, lassen
> sich aber trotzdem debuggen.

Das wäre auch erstmal meine Vermutung gewesen.

> Lokale nicht statische Variablen dagegen
> erzeugen keine Fehlermeldung, der Debugger kennt sie aber nicht.

Bist du dir sicher, dass die Variable überhaupt noch da ist?  Solche
Variablen werden gern vom Optmizier kassiert.

Leider wird VMlab nun schon seit Jahren nicht mehr weiter entwickelt,
da es sich für den Entwickler nicht rentiert hat.  Opensource wollte
er es auch nicht machen.  Ich vermute, falls sich jemand ernsthaft
ransetzen wöllte und das weiter pflegen möchte, dass man mit ihm sogar
in Verhandlung treten könnte.

Der AVR-COFF-Patch hat auch so viele bekannte Unzulänglichkeiten, dass
er eines kompletten Rewrites bedarf.  Das ist auch der Grund, warum ich
ihn nie offiziell bei den Binutils eingereicht habe.  Da es mittlerweile
außer VMlab keinen Grund mehr für dieses altertümliche (und noch dazu
von Atmel sehr schräg implementierte) Objektformat gibt, habe ich auch
keinerlei Motivation mehr für einen derartigen Rewrite.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bist du dir sicher, dass die Variable überhaupt noch da ist?  Solche
>Variablen werden gern vom Optmizier kassiert.

Sehr sicher - debuggen mit Optimizer ist leider noch zweckfreier. Das 
mache ich nur, wenn es ums timing geht, und die Funktion an sich geklärt 
ist.

Unschön ist auch sowas wie

bool isBoolscheFunktion(void)
...

Die erkennt VMLAB erst gar nicht.

Mein Traum wäre ja VMLAB open source, integriert in Eclipse.

Oliver

Autor: Martin Freund (martinf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Leider wird VMlab nun schon seit Jahren nicht mehr weiter entwickelt,
> da es sich für den Entwickler nicht rentiert hat.  Opensource wollte
> er es auch nicht machen.  Ich vermute, falls sich jemand ernsthaft
> ransetzen wöllte und das weiter pflegen möchte, dass man mit ihm sogar
> in Verhandlung treten könnte.

Es wird wieder weiterentwickelt, näheres dazu auf 
http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1234795683

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es wird wieder weiterentwickelt, näheres dazu auf
>http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1234795683

Es gibt tatsächlich eine neue Version, 3.14 !!! (und im Forum gibt es 
auch sachon ein 3.14A)

Zumindest das Problem

Beitrag "VMLAB Interrupt zu früh, Stackpointer falsch"

scheint behoben zu sein. Außerdem wird anscheinend auf im Forum 
gemeldete Bugs reagiert.

Oliver

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

Bewertung
0 lesenswert
nicht lesenswert
Martin Freund wrote:

> Es wird wieder weiterentwickelt, näheres dazu auf
> http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1234795683

Gut zu wissen.  Ich habe Enrique gleich mal 'ne Mail mit meinem
persönlichen Favoriten für eine Weiterentwicklung gemailt. ;-)  Das
wäre nämlich ein ELF-Parser, damit ich den ollen COFF-Patch dann mal
endgültig beerdigen kann.

Autor: Martin Freund (martinf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir mal 'nen COFF Patcher für das genannte Problem geschrieben.

Funktionsweise:
Das Programm überprüpft die Symboltabelle, wenn es auf eine statische 
Variable trifft und deren Adresse über 0x800000 liegt, so wird diese um 
den genannten Wert verringert.

Verwendung:
coffpp.exe "input.cof" "output.cof"
oder
coffpp.exe "input_and_output.cof"

Ausgelegt ist das Ganze für Windows, inwiefern sich die Quelldatei unter 
Linux o.ä. kompilieren lässt, hab ich noch nicht probiert.
Zu erwähnen ist noch, dass es sich hier um einen Hack handelt, der ein 
an sich fertiges Programm nachbearbeitet, wodurch eventuell andere 
Probleme entstehen können.
Deshalb rate ich auch davon ab, coffpp zu verwenden, wenn es nicht einen 
triftigen Grund dafür gibt.
Letztenendes dient der COFF Post Patcher lediglich dazu, die Zeit bis zu 
einem möglichen Bugfix zu überbrücken.

edit: Wieso hab ich die Dateiendung doppelt dran?

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

Bewertung
0 lesenswert
nicht lesenswert
Martin Freund wrote:
> Hab mir mal 'nen COFF Patcher für das genannte Problem geschrieben.

Da hätteste auch gleich den COFF-Patch selbst behacken können in
der Zeit.

> Letztenendes dient der COFF Post Patcher lediglich dazu, die Zeit bis zu
> einem möglichen Bugfix zu überbrücken.

Es wird zumindest von mir keine Änderungen am AVR-COFF-Patch mehr
geben.  Falls also nicht in endlicher Zeit VMlab doch mal einen
ELF-Parser implementiert, wird sich an diesem Zustand nichts ändern.

Sorry, aber ich habe einfach keinerlei Motivation dafür, dieses
gruselige Dateiformat nochmal anzufassen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Falls also nicht in endlicher Zeit VMlab doch mal einen
>ELF-Parser implementiert, wird sich an diesem Zustand nichts ändern.

Im VMLAB-Forum findet sich zu dem Thema ein Kommentar, der sinngemäß 
lautet, daß es leider keine manpower für die Erstellung eines elf-Parser 
gäbe, und man deshalb weiterhin mit coff leben muß )-:

Oliver

Autor: Martin Freund (martinf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver wrote:
>>Falls also nicht in endlicher Zeit VMlab doch mal einen
>>ELF-Parser implementiert, wird sich an diesem Zustand nichts ändern.
>
> Im VMLAB-Forum findet sich zu dem Thema ein Kommentar, der sinngemäß
> lautet, daß es leider keine manpower für die Erstellung eines elf-Parser
> gäbe, und man deshalb weiterhin mit coff leben muß )-:

Ich sehe das Problem eher im Lizenzgeplänkel. Wenn man auf die GPL 
umsteigen könnte, gäbs z.B. die Libdwarf. (vgl. 
http://wiki.dwarfstd.org/index.php?title=DWARF_FAQ)
Um ein paar Änderungen und ein komplettes Codereview wird man aber auch 
dann nicht herum kommen.

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

Bewertung
0 lesenswert
nicht lesenswert
Martin Freund wrote:

> Ich sehe das Problem eher im Lizenzgeplänkel. Wenn man auf die GPL
> umsteigen könnte, gäbs z.B. die Libdwarf.

Für Delphi?

Autor: Martin Freund (martinf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Martin Freund wrote:
>
>> Ich sehe das Problem eher im Lizenzgeplänkel. Wenn man auf die GPL
>> umsteigen könnte, gäbs z.B. die Libdwarf.
>
> Für Delphi?

Man kann C Objectdateien in Delphi einbinden. Dazu muss man aber noch 
die Externals näher spezifizieren. (vgl. 
http://rvelthuis.de/articles/articles-cobjs.html)
Hab das aber selber noch nie gemacht weil ich kein Delphi kann.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Man kann C Objectdateien in Delphi einbinden.

Und landet dann wieder im Lizenzgeplänkel...

Oliver

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.