Guten Tag zusammen,
ich habe am Wochenende versucht, den gcc für ARM zu übersetzen. Nach
einigen Problemen mit gmp und mpfr lief dann make wenigstens so weit
durch, dass ein ausführbarer gcc dabei herauskam. Schon mal ein Anfang.
ein einfaches
int main (void)
{
return (0);
}
konnte ich damit nicht komplett übersetzen und linken, aber immerhin
lies sich der gcc eine Assemblerdatei entlocken. Die sah von den
Befehlen her auch ganz brauchbar aus, d.h. es waren wirklich
ARM-Befehle.
OK, ich muss nun nochmal nachschauen, wo make scheitert. Dann habe ich
Probleme beim Linken, da der Linker ein crt0 erwartet. Evtl. wird der
falsche Linker, nämlich der meines Linux-Systems und nicht der aus den
ebenfalls selbst übersetzten binutils verwendet?
Lange Rede, kurzer Sinn: es wird wohl noch eine Fleißaufgabe werden, aus
dem jetzigen Erfolg zu einem installierbaren RPM zu kommen. Gibt's
irgendwelche brauchbaren Dokus, wie man da möglichst schnell zum Ziel
kommt? Die üblichen Verdächtigen bringen mich nicht wirklich weiter.
Vor allem: wie läuft das bei so einer Aktion mit der Laufzeitbibliothek?
Mein Compiler findet nicht mal stdlib.h, und auch ich finde die im
kompletten arm-gcc-Unterverzeichnis nicht.
Wie gesagt, ich habe nur make ausgeführt, noch kein make install, da ich
nicht händisch das Zeug wieder aus meinem System rauslöschen möchte.
Muss erst die Installationspfade setzen. Oder gleich ein RPM draus bauen
(lassen).
Wie ihr seht, eine Fragen sind noch offen.
Bin für jeden Tipp (außer: fertigen arm-gcc installieren) dankbar.
Danke!
Gast schrieb:
> Lange Rede, kurzer Sinn: es wird wohl noch eine Fleißaufgabe werden, aus> dem jetzigen Erfolg zu einem installierbaren RPM zu kommen. Gibt's> irgendwelche brauchbaren Dokus, wie man da möglichst schnell zum Ziel> kommt? Die üblichen Verdächtigen bringen mich nicht wirklich weiter.
Wie wär's mit Google? Anleitungen dazu lassen sich haufenweise finden,
z.B.:
http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_Xhttp://embdev.net/topic/129986#new> Vor allem: wie läuft das bei so einer Aktion mit der Laufzeitbibliothek?> Mein Compiler findet nicht mal stdlib.h, und auch ich finde die im> kompletten arm-gcc-Unterverzeichnis nicht.
Du brauchst die Newlib, siehe oben.
> Wie gesagt, ich habe nur make ausgeführt, noch kein make install, da ich> nicht händisch das Zeug wieder aus meinem System rauslöschen möchte.> Muss erst die Installationspfade setzen.
Mach das doch mal, im Build-Verzeichnis rumzubasteln macht die ganze
Sache nur zusätzlich kompliziert.
Gast schrieb:
> Wie gesagt, ich habe nur make ausgeführt, noch kein make install, da ich> nicht händisch das Zeug wieder aus meinem System rauslöschen möchte.> Muss erst die Installationspfade setzen. Oder gleich ein RPM draus bauen> (lassen).
Schau mal in die Hilfe zu deinem configure, da gibt es ein --Prifix und
du kann installieren wohin du willst. Auch nach /dev/nul ;-)
configure --help
oder
http://gcc.gnu.org/viewcvs/trunk/gcc/doc/install.texi?revision=152629&view=co
Johann
Hallo Leute,
zuerst einmal vielen Dank für Eure Antworten!
Ich habe jetzt die Toolchain mal sauber übersetzt, scheint alles zu
funktionieren. Nun habe ich allerdings ein kleines Problem mit der
Programmgröße: das kleinstmögliche Programm
void main (void) { return; }
wird ca. 75kByte groß. Da wird alles möglich dazugelinkt, wahrscheinlich
aus dem Startupcode heraus. Und wieso gibt's da ctors und dtors. Das
klingt irgendwie nach C++-Zeug. Ich habe allerdings nur mit "c"
übersetzt.
Wie bekomme ich den Ballast weg? Ja ja, ich geh' mal googeln, aber
vielleicht weiß hier ja trotzdem jemand Bescheid. Dann muss ich mich
noch kurz um die floating point Geschichte kümmern. Brauche ne Soft-FP
(na ja, eigentlich brauche ich gar keine FP-Arithmetik, da ich nur
ganzzahlig arbeite, aber wenn schon...)
Hallo Leute,
gleich das nächste Problem:
arm-elf-gcc -mthumb -mcpu=cortex-m3 test.c
liefert haufenweise Fehlermeldungen der Art:
arm-elf/bin/ld: ERROR: install/lib/gcc/arm-elf/4.4.1/thumb/crtn.o uses
hardware FP, whereas a.out uses software FP
ich würde das so interpretieren, dass newlib mit Hardware-FP übersetzt
wurde,
und gcc das Programm mit soft FP übersetzt. Google liefert ein paar
Infos, die aber allesamt nicht zum Erfolg führen.
ach ja, arm-elf-gcc test.c funktioniert ohne Probleme.
Ich hoffe, ich habe da als Target nichts falches angegeben (möchte einen
Cortex M3 verwenden, habe als target arm-elf gewählt. Passt das?)
Kann jemand helfen? Danke.
Hi,
kannst du mal deine Configure-Optionen hier posten? Würde mich
interessieren, wie du das mit gmp und mpfr hingekriegt hast, bei mir hat
das auch nicht funktioniert, als ich mit mingw32 für Windows übersetzen
wollte. Unter Cygwin (sowie auch bei mir unter Ubuntu) hat es mit
folgendem Tutorial funktioniert:
http://wiki.ubuntuusers.de/GNU_ARM-Toolchain
Folgende Versionen habe ich verwendet:
# GCC 4.4.1
# Binutils 2.19
# Newlib 1.17
# GDB 6.8
# Insight 6.8-1
Die Patcherei kannst du weglassen, wichtig ist nur, dass du beim GCC das
Thumb-Zeugs aktivierst (in der t-arm-elf die paar Zeilen
einkommentieren).
Oliver Behr schrieb:
> interessieren, wie du das mit gmp und mpfr hingekriegt hast, bei mir hat> das auch nicht funktioniert, als ich mit mingw32 für Windows übersetzen> wollte.
Am einfachsten geht das, indem man MPFR und GMP ins Toplevel
GCC-Direktory linkt (ln -s) bzw kopiert als mpfr bzw. gmp. Dann werden
beim generieren diese Pakete mit den richtigen Optionen miterzeugt. Mit
--with-gmp ist das schon was unangenehmer...
Johann
Hallo,
"Würde mich interessieren, wie du das mit gmp und mpfr hingekriegt
hast,"
Wie Johann bereits beschrieben hat: das Verzeichnis mit den ausgepackten
gmp- und mpfr-Quellen in den gcc-Ordner kopieren. Die Verzeichnisse
entsprechend "gmp" und "mpfr" nennen.
Hallo zusammen,
also, ich habe jetzt newlib und gcc nochmal mit der Option
--with-float=soft übersetzt. Das Testprogramm lässt sich nun linken.
Allerdings habe ich noch immer das Größenproblem:
arm-elf-size sagt:
text data bss dec hex filename
11620 2408 264 14292 37d4 a.out
also 14KB für ein leeres Programm. Mir ist schon klar, dass ein
Startupcode notwendig ist. Aber 14KB sind nicht gerade wenig.
Ach ja, weitere Frage hierzu: Ich muss doch sicher irgendwie
prozessorspezifische Parameter vor dem Übersetzen einstellen, damit der
Startcode auch das richtige macht. Ich denke so an RAM-Größe, Stackende,
etc. pp.
Vor allem habe ich bei luminary keinen entsprechenden Satz von Headern
und/oder Bibliotheken gefunden, nur eine ganze Umgebung mit schlappen
130MB. Werde nochmal auf der extrem übersichtlichen Website suchen.
In a.out sind irgendwelche Uhrzeitfunktionen und vieles andere mehr
drin. Gibt es eine Möglichkeit, für einfache Programme diesen Overhead
zu reduzieren? Google ist da leider nicht sehr gesprächig.
Irgendwie habe ich das Gefühl, ich sollte mich mal nach einem guten
Tutorial umsehen... ;-)
Danke für Eure Mithilfe.
Gast schrieb:
> Hallo zusammen,>> also, ich habe jetzt newlib und gcc nochmal mit der Option> --with-float=soft übersetzt. Das Testprogramm lässt sich nun linken.> Allerdings habe ich noch immer das Größenproblem:>> arm-elf-size sagt:>> text data bss dec hex filename> 11620 2408 264 14292 37d4 a.out>> also 14KB für ein leeres Programm. Mir ist schon klar, dass ein> Startupcode notwendig ist. Aber 14KB sind nicht gerade wenig.
Falls wie oben einfach mit einem aufruf von gcc compiliert und zu einem
a.out gelinkt wurde, wird mit dem Standard-Startup gelinkt. Normerleise
lässt man gcc erstmal mit -c aus dem Quellcode Objectcode erzeugen,
stellt eigenen Quellcode für Startup bereit compiliert diesen auch und
linkt dann beides mit -nostartfiles, damit die Standard-crt0 aussen vor
bleibt.
> Ach ja, weitere Frage hierzu: Ich muss doch sicher irgendwie> prozessorspezifische Parameter vor dem Übersetzen einstellen, damit der> Startcode auch das richtige macht. Ich denke so an RAM-Größe, Stackende,> etc. pp.
Größen und Adressen von Speicherbereichen werden im Linker-Script (oder
zur not mit Kommandozeilenoptionen zum Linker) festegelegt.
> Vor allem habe ich bei luminary keinen entsprechenden Satz von Headern> und/oder Bibliotheken gefunden, nur eine ganze Umgebung mit schlappen> 130MB. Werde nochmal auf der extrem übersichtlichen Website suchen.
So unübersichtlich nun auch nicht. Die "130MB" sind wahrscheinlich die
"DriverLib". Das ist keine "Umgebung" sondern eine etwas ausgeuferte
Sammlung von Beispielcode für alle möglichen TI/LMI-Boards nebst
Treiber-Codes. Darin sind auch einige makefiles, linkerscript und
startup-code für die GNU cross-toolchain, an denen man sich orientieren
kann.
> In a.out sind irgendwelche Uhrzeitfunktionen und vieles andere mehr> drin. Gibt es eine Möglichkeit, für einfache Programme diesen Overhead> zu reduzieren? Google ist da leider nicht sehr gesprächig.
Newlib-Quellcode liegt ja schon auf der Platte, man kann dort den
Quellcode der crt0 ansehen.
> Irgendwie habe ich das Gefühl, ich sollte mich mal nach einem guten> Tutorial umsehen... ;-)
Das "Gefühl" habe ich auch.
Nur als Hinweis auf die erf. Schritte die Ausgabe für die Übersetztung
eines meiner sehr alten Beispiele - genauer einer Portierung von
LMI-Code, als LMI selbst GNU-Tools noch nicht unterstützt hat.
Anwendungscode in hello.c, osram.c, uvision.c, startup-code in
startup_gcc.c, Linker-script ist lmi3s811.ld. Angelinkt wir auch noch
object-code aus einer "echten" Library libluminary.a (-lluminary), die
aus dem Quellcode der LMI DriverLib erzeugt wurde.
1
D:\users\mthomas\develop\arm\lm3s811_evalboard\ev-lm3s811\hello>make all
2
--
3
-------- begin (mode: ROM_RUN) --------
4
arm-eabi-gcc (devkitARM release 23b) 4.3.0
5
Copyright (C) 2008 Free Software Foundation, Inc.
6
This is free software; see the source for copying conditions. There is NO
7
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
