Forum: Compiler & IDEs Unterschiedliches Linking Resultat in Abhängigkeit von Größe einer section (GCC 4.8.0.2 )


von Reinhard (Gast)


Lesenswert?

Wir arbeiten auf einen RX74M mit GCC for Renesas 4.8.0.201603-GNURX 
Toolchain und haben da ein ungutes Phänomen. Ab einer bestimmten Größe 
des Programmspeichers der gelinkt wird ändert sich plötzlich die Linking 
Reihenfolge in einer anderen section.

Unser Projekt besteht aus Bootloader + Applikation welche sich einen 
gemeinsamen USB Host stack teilen. Dh. der bootloader startet benützt 
den USB Stack um nachzuschauen ob ein Stick angeschlossen ist und 
startet wenn nicht den Applikationsteil, welcher den gleichen USB Stack 
Teil verwendet um zB Daten auf den Stick zu schreiben.
Ist eine neue Version des Applikationsteils vorhanden startet der 
Bootloader nicht die Applikation sondern flasht den Applikationsteil und 
startet den neuen danach. Deshalb ist es wichtig, dass beim Linken des 
Projektes immer der gleiche Code für den Stack Teil herauskommt da 
ansonsten der Controller ja abstürzt wenn der neue Applikationsteil den 
Stack anders benützt.

Das komische daran ist, dass es schon ausreicht wenn der rodata Bereich 
der Applikation anwächst, also keine Funktionsaufrufe in der Lib o.ä. 
Nehmen wir an, dass ist die richtige linking order eines Teils der 
libgcc welcher in der Lib Section liegt:
P 0xfffee2c0 0x3d0 libgcc.a(_udivdi3.o)
0xfffee2c0 __udivdi3
0xfffee2c0 _COM_DIV64u

füge ich jetzt nur ein großes Array von const Daten im Applikationsteil 
hinzu (liegt in einer ganz anderen section) kommt plötzlich das heraus:
P 0xfffee2c0 0x3d0 libgcc.a(_udivdi3.o)
0xfffee2c0 _COM_DIV64u
0xfffee2c0 __udivdi3

Also die Position von Lib Funktionen in einer ganz anderen section sind 
verdreht, dass passiert aber zB auch mit RAM Variable welche die Library
nützt.

Wie kann so etwas sein? Hab dazu auch ein support query bei Renesas gcc 
gestartet, aber vielleicht kann mir von hier jemand weiterhelfen.

Danke im Voraus
Reinhard

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Reinhard schrieb:
> Wir arbeiten auf einen RX74M mit GCC for Renesas 4.8.0.201603-GNURX
> Toolchain und haben da ein ungutes Phänomen. Ab einer bestimmten Größe
> des Programmspeichers der gelinkt wird ändert sich plötzlich die Linking
> Reihenfolge in einer anderen section.

Wenn du bestimmte Reihenfolge von bestimmten Objekten brauchst, dann 
bilde das in einem passenden Linker Description File ab.

Wenn z.B. von a.c und b.c aus Objekte nach .data kommen, dann gibt es 
keine festgelegte Reihenfolge -- und aus besherigen Links eine 
Reihenfolge abzuleiten ist, naja, ein nicht-funktionierender Hack.

Der Linker hält das Zeug in irgendwelchen Datenstrukturen, z.B. 
Hash-Tabellen, so dass Hinzufügen von Objekten die Reihenfolge beim 
Traversen ändern kann.

von Oke (Gast)


Lesenswert?

Ich wollte nur mal in den Raum werfen, dass sich bei diesem Verfahren 
auch die RAM aufteilung ändern kann. Wenn also deine doppelt genutzten 
Programmteile RAM Speicher allozieren, so kann auch dieser "wandern", 
wenn der Linker neu gestartet wird.

Mit Tools wie "srec_cut" kann man auch den Flash Inhalt layouten.
Man klebt quasi den Flash aus den einzelnen Teilen zusammen.
Gefährlich ist das o.g. Verfahren nämlich auch noch in Bezug auf Flash 
Segment Grenzen. Sollte deine Applikation nicht genau auf einer 
Segmentgrenze starten, dann wird bei einem Update der Applikation u.U. 
auch teile gelöscht die du nicht löschen willst.


mfg

von Reinhard (Gast)


Lesenswert?

Danke für eure Antworten!

>Wenn z.B. von a.c und b.c aus Objekte nach .data kommen, dann gibt es
>keine festgelegte Reihenfolge
Nur zu meinem Verständnis, warum ist das so? Über das sections skript 
schieb ich natürlich die bootloader .o und funktionen der libgcc.a 
welche ich für beide brauche in fixe sections (sowohl ROM+RAM). Aber 
woher kommt das der Linker die Reihenfolge der zB Funktionen anders 
positioniert obwohl sich bezüglich Aufrufe oder Speicherbedarf in dieser 
section bzw .o nichts ändert?

Nachdem wir da was anscheinend nicht in der Hand haben (ausser LD files 
sind einen Versuch wert..), werde ich Bootloader und Applikation wieder 
trennen. Nachdem die CPU 4MB Flash hat kann jeder Teil seinen eigenen 
USB Stack haben, nur war die Idee eben Flash (RAM) zu sparen für 
Projekte wo weniger Flash zur Verfügung steht.

>Mit Tools wie "srec_cut" kann man auch den Flash Inhalt layouten.
>Man klebt quasi den Flash aus den einzelnen Teilen zusammen.
Danke werden ich mir anschauen und dann wohl Bootloader + Applikation 
zusammenkleben :)

Reinhard

von Reinhard (Gast)


Lesenswert?

Niemand eine Idee warum die Reihenfolge vertauscht sein kann?

Danke im Voraus

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Reinhard schrieb:
> Niemand eine Idee warum die Reihenfolge vertauscht sein kann?

Schrieb Johann dir doch schon: weil es der Linker eben irgendwie
entscheiden kann und darf, sofern ihm nicht der Linkerscript etwas
konkretes vorschreibt.

Wenn du wirklich wissen willst, warum er sich im konkreten Fall
mal so, mal so entschieden hat, dann wirst du wohl oder übel in den
Linkerquellen herumwühlen müssen.

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.