Hi
Bisher haben meine Versuche gescheitert, dieses Beispiel von Miro Samek
(http://en.mikrocontroller.net/topic/113459) mit WinARM zu kompilieren.
Ich habe das Proejkt dann "geringfügig" umgemodelt.
Dieses Ummodeln bestand hauptsächlich im Ändern des Linkerscripts:
http://web3.veesi.de/ARM/AT91SAM7S64-ROM-TOBI.ld
Ich habe den AT91SAM7S64-ROM.ld von Martin Thomas als Vorbild genommen,
und und zumindest versucht um die Funktionen des Samek-Scripts zu
erweitern.
Dabei trat das Problem auf, dass in der .data section, die ja im RAM vom
Startupcode platziert werden soll, aber im ROM gespeichert werden soll,
die Loadadresse nicht generiert wurde (obwohl das genau gleich
formuliert war wie für .fastcode).
Ich habe einfach je eine Section gemacht, einmal im RAM und einmal im
ROM.
Kann ich das so machen? / Ist das gut so?
Ist der Linkerscript allgemein benutzbar?
Diese Linkerscriptgeschichte finde ich am schlimmsten, weil einem keiner
so richtig weiterhelfen kann. Viele Beispiele sind zwar gut, aber ein
gutes Tutorial ersetzen sie leider auch nicht.
Soweit so gut.
1
D:\dat-loc-tobi\Programming\ARM\Projects\std-code-try1>make all
2
3
.compiling
4
arm-elf-gcc -I./ -c -fno-common -O0 -g main.c
5
6
/*[...]*/
7
/*Kompiliert und assembliert sourcen ohne mullen und knullen*/
C:/WinARM/arm-elf/lib/libc.a(init.o): In function `__libc_fini_array':
18
init.c:(.text+0x3c): undefined reference to `_fini'
19
20
C:/WinARM/arm-elf/lib/libc.a(init.o): In function `__libc_init_array':
21
init.c:(.text+0x80): undefined reference to `_init'
22
23
make: *** [main.out] Error 1
Diese beiden Fehlermeldungen spuckt der Linker jetzt noch aus. An was
kann das liegen?
Ich hab mal bei google gesucht, da hieß es irgendwo, es gäbe einen
Fehler in der Lib...
Glaub ich jetzt aber ned. Muss irgendwie am Linkerscript liegen?
Falls ihr euch das ganze Projekt anschauen wollt:
http://web3.veesi.de/ARM/std-code-try1.zip
Ich weis nicht. Bin ich einfach nur zu blöd oder ist das wirklich so
schwer? - Wohl ersteres ;)
Danke schonmal,
Tobi
C:/WinARM/arm-elf/lib/libc.a(init.o): In function `__libc_fini_array':
10
init.c:(.text+0x3c): undefined reference to `_fini'
11
12
C:/WinARM/arm-elf/lib/libc.a(init.o): In function `__libc_init_array':
13
init.c:(.text+0x80): undefined reference to `_init'
die Fehlermeldung besagt ja, dass der Linker ein bestimmtes Symbol nicht
findet - ich vermute aber, dass du dieses Symbol gar nicht brauchst. Die
undefinierte Referenz könnte daher kommen, dass du evtl. die Komplette
Bibliothek libc.a einbindest, nicht nur die Teile, die auch benötigt
werden. Dabei bin ich mir aber nicht zu 100% sicher, aber mir kommt dein
ld-Aufruf etwas seltsam vor, ich würde den ld eher so aufrufen:
Ich weiß, wie bereits gesagt, nicht genau, ob es einen Unterschied
macht, die Bibliothek direkt als Eingabedatei anzugeben, oder mit '-l'.
Evtl. müsste man die Pfade mit '-L' auch gar nicht mehr explizit
angeben, weil es die Standard-Pfade sein müssten, in denen der
arm-elf-ld sowieso sucht.
Ciao, Fabian
- Wird das init aus der libc wirklich benötigt? Falls man die
Initialisierung "von Hand" macht, kann man mit -nostartfiles linken
- Besser über das Compiler-Frontend (arm-elf-gcc) Linken. Dieses "weiss"
wo die passende libc abgelegt ist, Pfadangaben kann man sich dann
sparen.
(.text+0x140): undefined reference to `__data_load'
4
c:\winarm\bin\../arm-elf/lib\libc.a(init.o): In function `__libc_fini_array':
5
init.c:(.text+0x3c): undefined reference to `_fini'
6
c:\winarm\bin\../arm-elf/lib\libc.a(init.o): In function `__libc_init_array':
7
init.c:(.text+0x80): undefined reference to `_init'
8
arm-elf-ld: BFD 060606 20060606 internal error, aborting at c:/winarms/binutils-060606/bfd/elflink.c
9
line 6509 in elf_link_output_extsym
10
11
arm-elf-ld: Please report this bug.
__data_load wird im Linkerscript in Zeile 110 deklariert.
__data_load wird dann im Startupcode verwendet (startup.s, Z. 100)
(siehe Link zum Projekt):
1
[...]
2
/* Relocate the .data section (copy from ROM to RAM) */
3
LDR r0,=__data_load
4
LDR r1,=__data_start
5
[...]
Aber warum ist es eine "undefined reference"? Ich meine es wird ja auch
die .fastcode Sektion im ">RAM AT>ROM" abgelegt und da wird die
Loadadresse definiert, und da klappts ja wunderbar.
Danke für eure Hilfe, ich hab echt keine Ahnung mehr...
Viele Grüße,
Tobi
Für das konkrete Problem mit .data testweise mal im Code zwei globale
Veriablen anlegen:
1
volatileintdummy1=123;// sollte in .bss
2
volatileintdummy2;// sollte in .data
3
4
//dann irgendwo am Anfang von main
5
...
6
dummy2=dummy1;
7
dummy1=dummy1;
8
...
Dann im Map-File nachsehen, an welchen Addressen die beiden Symbole
angelegt werden und ob die .bss und .data Start-/Ende-Addressen, die im
Startup für's bss "ausnullen" und .data kopieren genutzt werden, die
Symboladdressen der dummys "einschliessen". Gab/Gibt beim linker
manchmal Probleme, wenn .data leer ist. Mit den Ansatz sollte man das
analysieren können.
Die Beispiele aus der embedded.com Artikelserie sind für eine GNU
arm-eabi toolchain vorbereitet. Mein WinARM-Packet und Michael Fischers
Yagarto enthalten in den momentan "offizellen" Versionen arm-elf
toolchains. Es gibt zwar eine WinARM Testversion mit arm-eabi Toolchain
aber das ist wirklich nur eine Testversion. Nicht alle enthaltenen
Beispiele funktionieren, vgl. Thread auf en.mikrocontroller.net. Es gibt
da ein paar Unterschiede zwischen arm-eabi und arm-elf. Bin selbst noch
dabei, alle Unterschiede zu analysieren aber grade zu wenig Zeit dafür.
Falls man den Beispielcode zur Artikelserie nachvollziehen will und
nicht gleich viel an Linker-Skript und Startup-Code herumbasteln will,
dürfte es am Einfachsten sein, die vorkompilierte "bare-metal"-Toolchain
von Codesourcery zu verwenden. Die Lite-Version gibt's kostenlos zum
Download und man kann diese problemlos neben WinARM oder Yagarto
installiert. Lite heisst nur, dass man kein vorkonfiguriertes Eclipse
und keinen Support von Codesourcery bekommt (o.k, man kann auf "gratis"
Antworten in deren Forum hoffen), es gibt keine Beschränkung im Hinblick
auf die Codegröße.
Hi!
Ich... ich...
...bin Sprachlos.
...und (fast) glücklich.
Das war der Fehler! Der Linker meckert jetzt "nur" noch an "_fini" und
"_init".
Unglaublich.
Die Variablen werden auch laut map-file genau da abgelegt, wo sie hin
sollen:
c:\winarm\bin\../arm-elf/lib\libc.a(init.o): In function `__libc_fini_array':
6
init.c:(.text+0x3c): undefined reference to `_fini'
7
c:\winarm\bin\../arm-elf/lib\libc.a(init.o): In function `__libc_init_array':
8
init.c:(.text+0x80): undefined reference to `_init'
Könnten sich da vllt. 2 Libraryversionen in die Quere kommen? Oder der
Linkerscript ist auf eine eine andere Version abgestimmt oder sowas in
der Richtung?
Hm.
Danke Martin auf jeden Fall für deine Hilfe, das hat mich Kilometer
weiter gebracht!
Viele Grüße,
Tobi
Wenn ja, einfach testweise erstmal rauswerfen. Die Funktion braucht man
nach meinem Verständnis nur zum Aufruf der CTORS von statischen
C++-Objekten, die es in einem "normalen C"-Projekt ja nicht gibt, und
hat ein paar Abhängigkeiten, die wohl die Ursache für das
"Linkergemecker" sind.
Vielen, vielen Dank, Martin!
Mensch, wenn man weis, an was es lag, kommt man sich so (unglaublich)
doof vor, aber ich glaube ich habe den Wald vor lauter Bäumen nichtmehr
gesehen ;)
Einmal Suchen hätte ja gereicht. . .
Au mann.
Trotzdem Danke!
Jetzt kanns weiter gehen - Mal sehen was noch so auf mich zu kommt...
Viele Grüße, und Danke nochmal!
Tobi
Ich darf mich auch bedanken. Habe ein example Linkerscript und startup
code verwendet. Im startup file wurde das Symbol __libc_init_array
angesprungen. Welches er wohl in der libc nicht finden konnte. Ich habe
jetzt mal die entsprechende Zeile entfernt, und siehe da - er linkt brav
wie er soll!
Ich hoffe jetzt nur das ich diese Function wirklich nicht benötige, und
diese wirklich nur für C++ Geschichten verwendet wird.
Ihr habt mir den Tag gerettet. ;) Danke.
Hallo,
was genau war beim startup-file oder Linker script der Fehler?
Wir bzw. ich habe das selbe Problem.
Verwende Eclipse + OpenOCD + CodeSourcery Lite "Toolchain" - ist
eigentlich nur eine Compilersuite - und habe den selben bzw. den
gleichen Fehler.
Kannst du mir das startup-file + ld skript schicken?
LG,
Roman & Philipp