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:
1
intmain(void)
2
{
3
staticcharc=0;
4
for(;c<10;c++);
5
6
return0;
7
}
Warnungen beim Aufruf von "make coff" bzw. "make extcoff":
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.ru%2Fforum%2Flofiversion%2Findex.php%2Ft42835.html&sl=ru&tl=en&hl=de&ie=UTF-8
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
>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
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
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.
>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
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
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.
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:
1
coffpp.exe "input.cof" "output.cof"
oder
1
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?
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.
>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
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.
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.
Thread beobachten
Seitenaufteilung abschalten