Forum: Compiler & IDEs section .stack is not within region RAM


von Thomas B. (quix01)


Angehängte Dateien:

Lesenswert?

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.

von Martin Thomas (Gast)


Lesenswert?

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

von Thomas B. (quix01)


Lesenswert?

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

von Quix01 (Gast)


Lesenswert?

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.

von Martin Thomas (Gast)


Lesenswert?

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

von Thomas B. (quix01)


Lesenswert?

> "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
Noch kein Account? Hier anmelden.