Hallo Leute, bin am Einarbeiten mit gcc 4.1.0 (aktuelles WinARM) und LPC2138 etc. Habe ein Minimalbeispiel (Anhang) in WinAVR erstellt und bekomme nun die Linker-Meldung: section .stack is not within region RAM Hab herausgefunden, dass die aktuelle .stack - Addresse nicht bei 0x4000.... sondern bei 0x0000.... liegt (siehe main.map). Im Linkerscript scheint etwas nicht zu stimmen mit dem Hochzählen der RAM-Addressen. Sobald eine Variable in .bss oder .data liegt, bekommt der Linker es aber gebacken. Was ist da los, ich kenne mich leider noch nicht so gut mit ld aus. Kann mir jemand weiterhelfen? Ciao Thomas.
Gast
#367533
WinARM mit gcc 4.1.1 ist aktuell (WinARM 20060606). Aber das "Problem"
ist auch mit der aktuellen Fassung reporduzierbar. In der
WinARM-Readme-Datei (Changelog) habe ich das auch erwaehnt (ok, nur
Warmduscher lesen Readme-Dateien, ich weiss). Ganz sicher bin ich mir
betr. der Ursache auch nicht, es tritt nur bei "Mini-Mini-Beispielen"
auf, in denen es nichts in in BSS gibt.
Abhilfe: ".stack" im linker-script so abaendern:
.stack :
{
. = ALIGN(256);
. += STACK_SIZE;
PROVIDE (_stack = .);
} > RAM
Hoffe, es hilft
Martin Thomas
Danke für den Tip, jetzt funzts. War mir nicht sicher, ob "echte" Programme später von diesem Verhalten des ld betroffen sind. Vielleicht kann diese Script-Änderung auch mit in die nächste Version der WinARM-Beispiele rein :-) Ciao Thomas Blumenbach. P.S.: sitz grad am anderen Rechner, hier ist tatsächlich nicht die 20060606 drauf :-o
Gast
#367535
funzt doch noch nicht so ganz, zumindest beim Proggen kommt es zu einer
Fehlermeldung, dass der code jetzt bei 0x4000... beginnt.
Anscheinend muss sowohl das stack-segment selbst, als auch innerhalb
mit ALIGN() ausgerichtet werden. Also neu:
.stack ALIGN(256) :
{
. = ALIGN(256);
. += STACK_SIZE;
PROVIDE (_stack = .);
} > RAM
Ciao Thomas.
Gast
#367536
Sorry, mit "beim Proggen" kann ich nichts anfangen. Aber da es mit den
beiden Aligns anscheinend funktioniert, ist es ja gut. Obwohl ich nicht
wirklich verstehe, was das bringen soll, bzw. welchen Einfluss ein
Align bei .stack auf die Positionierung von .text ("Code") haben
soll.
Im Zweifel mag es bei Mini-Beispielen ohne Inhalt fuer BSS und DATA
noch helfen ein . = ORIGIN(RAM); vor die Definition vom .data
einzufuegen, das sollte "." dann korrekt fuer RAM initialisieren. Mit
arm-elf-ld --verbose kann man sich das default linker-Skript anschauen,
bringt vielleicht weitere Erkenntnisse.
Martin Thomas
> "beim Proggen"
ich nutze lpc21isp.exe und da wird neben der Prüfsummenberechnung (für
Addr. 0x00000014) anscheinend noch weiter analysiert, was in der
.hex-Datei drinsteht. Dort kam dann jedenfalls die Fehlermeldung her.
arm-elf-gcc und arm-elf-ld liefen ohne erkennbare Auffälligkeiten
durch.
Ich verstehe es auch nicht so ganz, aber der erzeugte Code läuft nun.
Ggf. weiss ich ja, woran zu drehen ist :-)
Ciao Thomas.