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.
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
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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.