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_X http://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. |
8 | |
9 | |
10 | Compiling C: hello.c |
11 | arm-eabi-gcc -c -mthumb -mcpu=cortex-m3 -mthumb-interwork -I. -gdwarf-2 -DROM_RU |
12 | N -Dgcc -D__WinARM__ -D__WINARMSUBMDL_lm3s811__ -Os -ffunction-sections -fdata- |
13 | sections -Wall -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-t |
14 | ype -Wshadow -Wunused -Wa,-adhlns=hello.lst -Wcast-qual -MD -MP -MF .dep/hello |
15 | .o.d -Wnested-externs -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmi |
16 | ssing-declarations hello.c -o hello.o |
17 | |
18 | Compiling C: startup_gcc.c |
19 | arm-eabi-gcc -c -mthumb -mcpu=cortex-m3 -mthumb-interwork -I. -gdwarf-2 -DROM_RU |
20 | N -Dgcc -D__WinARM__ -D__WINARMSUBMDL_lm3s811__ -Os -ffunction-sections -fdata- |
21 | sections -Wall -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-t |
22 | ype -Wshadow -Wunused -Wa,-adhlns=startup_gcc.lst -Wcast-qual -MD -MP -MF .dep |
23 | /startup_gcc.o.d -Wnested-externs -std=gnu99 -Wmissing-prototypes -Wstrict-pro |
24 | totypes -Wmissing-declarations startup_gcc.c -o startup_gcc.o |
25 | |
26 | Compiling C: ../osram96x16.c |
27 | arm-eabi-gcc -c -mthumb -mcpu=cortex-m3 -mthumb-interwork -I. -gdwarf-2 -DROM_RU |
28 | N -Dgcc -D__WinARM__ -D__WINARMSUBMDL_lm3s811__ -Os -ffunction-sections -fdata- |
29 | sections -Wall -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-t |
30 | ype -Wshadow -Wunused -Wa,-adhlns=../osram96x16.lst -Wcast-qual -MD -MP -MF .d |
31 | ep/osram96x16.o.d -Wnested-externs -std=gnu99 -Wmissing-prototypes -Wstrict-pr |
32 | ototypes -Wmissing-declarations ../osram96x16.c -o ../osram96x16.o |
33 | |
34 | Compiling C: ../../utils/uvision.c |
35 | arm-eabi-gcc -c -mthumb -mcpu=cortex-m3 -mthumb-interwork -I. -gdwarf-2 -DROM_RU |
36 | N -Dgcc -D__WinARM__ -D__WINARMSUBMDL_lm3s811__ -Os -ffunction-sections -fdata- |
37 | sections -Wall -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-t |
38 | ype -Wshadow -Wunused -Wa,-adhlns=../../utils/uvision.lst -Wcast-qual -MD -MP |
39 | -MF .dep/uvision.o.d -Wnested-externs -std=gnu99 -Wmissing-prototypes -Wstrict |
40 | -prototypes -Wmissing-declarations ../../utils/uvision.c -o ../../utils/uvision. |
41 | o |
42 | |
43 | Linking: main.elf |
44 | arm-eabi-gcc -mthumb -mcpu=cortex-m3 -mthumb-interwork -I. -gdwarf-2 -DROM_RUN - |
45 | Dgcc -D__WinARM__ -D__WINARMSUBMDL_lm3s811__ -Os -ffunction-sections -fdata-sec |
46 | tions -Wall -Wimplicit -Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type |
47 | -Wshadow -Wunused -Wa,-adhlns=hello.lst -Wcast-qual -MD -MP -MF .dep/main.elf |
48 | .d hello.o startup_gcc.o ../osram96x16.o ../../utils/uvision.o --output m |
49 | ain.elf -nostartfiles -Wl,-Map=main.map,--cref,--gc-sections -lc -lm -lc -lgcc |
50 | -L../../ -lluminary -T../lm3s811-ROM.ld |
51 | |
52 | Creating load file for Flash: main.bin |
53 | arm-eabi-objcopy -O binary main.elf main.bin |
54 | |
55 | Creating Extended Listing: main.lss |
56 | arm-eabi-objdump -h -S -D main.elf > main.lss |
57 | |
58 | Creating Symbol Table: main.sym |
59 | arm-eabi-nm -n main.elf > main.sym |
60 | |
61 | Size after: |
62 | main.elf : |
63 | section size addr |
64 | .text 2400 0 |
65 | .bss 4 536870912 |
66 | .stackarea 260 536870916 |
67 | .comment 284 0 |
68 | .debug_aranges 1184 0 |
69 | .debug_pubnames 2675 0 |
70 | .debug_info 7188 0 |
71 | .debug_abbrev 2169 0 |
72 | .debug_line 3330 0 |
73 | .debug_frame 2424 0 |
74 | .debug_str 2939 0 |
75 | .debug_loc 4372 0 |
76 | .debug_ranges 1208 0 |
77 | .ARM.attributes 49 0 |
78 | Total 30486 |
79 | |
80 | |
81 | |
82 | Errors: none |
83 | -------- end -------- |
84 | |
85 | |
86 | D:\users\mthomas\develop\arm\lm3s811_evalboard\ev-lm3s811\hello> |
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.