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
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.
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
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
Niemand eine Idee warum die Reihenfolge vertauscht sein kann? Danke im Voraus
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.