Forum: Compiler & IDEs GCC cross compile / libgcc.a verweist in leeren speicher bereich


von Eugen G. (audiflitzer)


Lesenswert?

Hallo zusammen,

ich bin neu hier und erhoffe das ich helfen kann wie auch mir geholfen 
werden kann.

Mein Problem:
Ich habe ein cross compiler für den arm erstellt (arm-none-eabi).
Dazu habe ich zuerst den gcc erstellt dann die newlib und anschließend 
die libgcc. Nach dem das fertig war erneut den gesamten GCC mit den lib 
und headers compiliert.

Als einstellungen sind --target=arm-none-eab --enable-multilib 
--enable-interwork --disable-werror --disable-shared --with-newlib 
--enable-languages=c,c++ --with-sysroot="dir mit allen libs und header"

Nun alles fertig. Ich kann den Quellcode compilieren, alles geht AUßER,
wenn ich variablen vom typ "double a = 0.343, b = 344.6, c=3.4;" anlege
und damit eine Rechnung mache z.B. "a = (b * c) / a;" dann springt der 
Programmcounter bei der Berechnung in einen Address bereich wo nichts 
hinterlegt ist alles nur 0xFFFF.

Wie ich beim Disassemblieren sehen konnte und das internet hat es auch 
bestätigt das für bestimmte Rechnung Funktionen aus der libgcc für 
solche rechnung benötigt wird. Die Routine die bei mir aus libgcc 
aufgerufen wird ist:
"double __muldf3 (double a, double b)"

Nach dem es in den Funktionsteil reinspringt kommt zwei befehle weiter 
ein sprungbefehl und der zeigt ins leere.

WARUM????

Ich habe diese Probleme mit dem GCC-4.6.3, GCC-4.7.0 und GCC-4.7.1

Was muss ich ändern?
Die libgcc liegt als static vor "libgcc.a"

Wenn ich den GCC-4.6.3 von codesourcery verwende gibt es kein Problem.
Die Makefile und den linkerskript den ich geschrieben habe verwende ich
sowohl bei codesourcery wie auch beim meinem compiliertem gcc.
Bei codesourcery gehts und bei mir nicht

WARUM???

Bitte um Hilfe, danke

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


Lesenswert?

Wie sieht denn die Ausgabe von
1
arm-non-eabi-nm <deine ELF-Datei>

aus?

von Eugen G. (audiflitzer)


Lesenswert?

Hier mein auszug aus:
arm-none-eabi-nm <meine elf datei>

08000c0c T __aeabi_ddiv
0800097c T __aeabi_dmul
08000c0c T __divdf3
0800097c T __muldf3
20000000 B _beginOfBss
20000000 T _beginOfData
20000010 B _endOfBss
20000000 T _endOfData
200027fc A _endOfStack
08000e78 T _endOfText
08000654 T _exception_bus_fault
0800062c T _exception_hard_fault
08000640 T _exception_memory_management_fault
08000618 T _exception_nmi
080006a4 T _exception_pend_sv
08000578 T _exception_reset
0800067c T _exception_sv_call
080006b8 T _exception_sys_tick
08000668 T _exception_usage_fault
080006e0 t _interrupt_pvd
0800072c t _interrupt_spi1
080007e8 t _interrupt_tim6
080007a4 t _interrupt_usart1
080007bc t _interrupt_usart2
080006f4 t _interrupt_usb_hp
08000708 t _interrupt_usb_lp
080007d4 t _interrupt_usb_wakeup
080006cc t _interrupt_wwdg
08000040 T _interruptvector
08000000 T _startupvector
20000004 B callback_func_spi1_rx
20000000 B callback_func_spi1_tx
20000008 B callback_func_tim6
2000000c B callback_func_usb
08000124 T gpioa_init
08000290 T gpiob_init
080002bc T gpioc_init
080002e8 T gpiod_init
08000314 T gpioe_init
08000340 T gpioh_init
080004e0 T main
08000e18 T strlen
08000370 T system_initial
08000948 T usart2_func_print_out_char
080008ec T usart2_func_print_out_str
0800080c T usart2_init

von Wichtige Regel (Gast)


Lesenswert?

>Wenn ich den GCC-4.6.3 von codesourcery verwende gibt es kein Problem.

Dann tu' das doch einfach.
Oder ist Cross-Compiler generieren Dein Hobby?

Ansonsten: Hardfloat oder Softfloat-Option  beim ./configure und/oder
beim Compilieren?
Möglicherweise hat Dein eigenerzeugter Compiler andere
arch- und cpu defaults wie der Codesourcery.
GCC-Manual sollte Auskunft geben.

Was sagt

$ xxx-gcc -v?

Bei CS kommt da:

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/CodeSourcery/arm-2012.03/bin/../libexec/g 
cc/arm-none-eabi/4.6.3/lto-wrapper
Target: arm-none-eabi
Configured with: 
/scratch/nsidwell/arm/eabi/src/gcc-4.6-2012.03/configure 
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu 
--target=arm-none-eabi --enable-threads --disable-libmudflap 
--disable-libssp --disable-libstdcxx-pch 
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld 
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2012 
-D__CS_SOURCERYGXX_MIN__=3 -D__CS_SOURCERYGXX_REV__=56 
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}} 
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: 
-fremove-local-statics}}}' --enable-languages=c,c++ --disable-shared 
--enable-lto --with-newlib --with-pkgversion='Sourcery CodeBench Lite 
2012.03-56' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ 
--disable-nls --prefix=/opt/codesourcery --with-headers=yes 
--with-sysroot=/opt/codesourcery/arm-none-eabi 
--with-build-sysroot=/scratch/nsidwell/arm/eabi/install/arm-none-eabi 
--with-gmp=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-none- 
eabi-i686-pc-linux-gnu/usr 
--with-mpfr=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-none 
-eabi-i686-pc-linux-gnu/usr 
--with-mpc=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-none- 
eabi-i686-pc-linux-gnu/usr 
--with-ppl=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-none- 
eabi-i686-pc-linux-gnu/usr  --with-host-libstdcxx='-static-libgcc 
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-cloog=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-non 
e-eabi-i686-pc-linux-gnu/usr 
--with-libelf=/scratch/nsidwell/arm/eabi/obj/host-libs-2012.03-56-arm-no 
ne-eabi-i686-pc-linux-gnu/usr  --disable-libgomp 
--enable-poison-system-directories 
--with-build-time-tools=/scratch/nsidwell/arm/eabi/install/arm-none-eabi 
/bin 
--with-build-time-tools=/scratch/nsidwell/arm/eabi/install/arm-none-eabi 
/bin
Thread model: single
gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-56)

Wenn Du die hier gelisteten ./configure Optionen nimmst, sollte es
klappen...

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


Lesenswert?

Eugen G. schrieb:
> Hier mein auszug aus:
> arm-none-eabi-nm <meine elf datei>
>
> 08000c0c T __aeabi_ddiv
> 0800097c T __aeabi_dmul
> 08000c0c T __divdf3
> 0800097c T __muldf3

Da sind deine Routinen zumindest erstmal dabei.

Nun musst du noch denjenigen fragen, der den Inhalt der ELF-Datei
in den Flash übertragen hat, wie viele Bytes er denn rübergeschoben
hat bzw. warum er diese nicht mitgenommen hat.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Wichtige Regel schrieb:

> Bei CS kommt da:
>
> arm-none-eabi-gcc -v
>
> [viele viele configure-Optonen die eine spezielle Build-Umgebrung bauchen]
>
> Wenn Du die hier gelisteten ./configure Optionen nimmst, sollte es
> klappen...

Das geht so nicht.

Du kannst nicht einfach die gleichen configure-Optionen auf einem 
komplett anders eingerichteten Rechner nehmen und erwarten, daß das ohne 
Anpassung geht.

Davon ab sind da noch einige $ drinne...

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> Eugen G. schrieb:
>> Hier mein auszug aus:
>> arm-none-eabi-nm <meine elf datei>
>>
>> 08000c0c T __aeabi_ddiv
>> 0800097c T __aeabi_dmul
>> 08000c0c T __divdf3
>> 0800097c T __muldf3
>
> Da sind deine Routinen zumindest erstmal dabei.

Hat nicht viel zu bedeuten. Was zählt ist nicht die Adresse, sondern die 
Größe bzw. der Code an der Stelle.

Wird eine Funktion nicht erzeugt weil sie nicht gebraucht wird, wird sie 
leer erzeugt.

Beispiel: __mulqi3 zur  8 = 8 x 8  Multiplikation in der libgcc von 
avr-gcc falls es ein MUL gibt.

Es ist also irgendwas mit den Optionen und/oder der 
Multilib-Konfiguration faul.  Ich tipp mal die Funktionen sind leer.

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


Lesenswert?

Johann L. schrieb:
> Ich tipp mal die Funktionen sind leer.

Da er schrieb, dass an der entsprechenden Stelle der Flash 0xFFFF hat,
würde das nicht passen.  Daher ist eher meine Vermutung, dass beim
Extrahieren der Flash-Daten aus der ELF-Datei was schief gelaufen ist.

von Eugen G. (audiflitzer)


Lesenswert?

Hallo,

danke für eure antworten!
Nach vielem probieren habe ich mein problem wohl gefunden, weiß nur 
nicht wie ich es lösen soll.

Nach dem ich make all-gcc ausführe und es installiert habe, führe ich
make all-target-libgcc aus um die libgcc.a zu erstellen.

Hier ist das Problem:
Beim compilieren sehe ich das die Einstellungen -mfloat-abi=hard ist und 
die optimierung auch auf -O2 ist.

Wie kann ich diese Einstellungen separat für diesen build make 
all-target-libgcc ändern? -> Ich denke das hier der haken ist!

Bei ./configure habe ich schon --with-float=soft angegeben ändert aber 
nichts für den libgcc build prozess.

Gruß

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.