[U-Boot] "raise" not defined, when compiler uses its own div0
When trying to build U-Boot under Buildroot and OpenEmbedded, I run into a problem:
When linking u-boot the linker seems to use the div0 from the C compiler libgcc instead of the u-boot div0.
gcc div0 for ARM contains a call to "raise" which is not defined in libgcc.a (someone said it was part of glibc), so the linking process fails due to no "raise" symbol
gcc/config/arm/lib1funcs.asm contains:
FUNC_START div0
tmfd sp!, {r1, lr} mov r0, #SIGFPE bl SYM(raise) __PLT__ ...
The problem can be fixed by patching the C compiler:
+ bl SYM(raise) __PLT__ + bl SYM(_div0) __PLT__
------ What I'd like to know: Is there a way to fix this in u-boot?
Tried creating a "raise" function in libarm/board.c void raise(void) { hang(); }
which did not work.
I later saw that raise needs a parameter, but it complained that raise is not found, and not that the parameters is wrong.
Is board.c not included in the link?
Anyone else got this problem?
BR Ulf Samuelsson
Ulf Samuelsson wrote:
When trying to build U-Boot under Buildroot and OpenEmbedded, I run into a problem:
When linking u-boot the linker seems to use the div0 from the C compiler libgcc instead of the u-boot div0.
Yes i had the same problem with a home made toolchain (eglibc-2.10, gcc-4.4.1| gcc-4.3.4 | gcc-4.3.3 | gcc-4.3.2) with smdk2410 board. It seems to be same with this thread http://lists.denx.de/pipermail/u-boot/2009-August/058349.html with codesourcery's toolchain. However, I have tested u-boot-arm repository which includes a controversial :-) "ARM: Don't include libgcc anymore" (70163a381f1a5c93fcc181365cdb092566d8c5c5) without compile errors.
Regards
Dear Gaye Abdoulaye Walsimou,
In message 4A81285B.8010908@walsimou.com you wrote:
However, I have tested u-boot-arm repository which includes a controversial :-) "ARM: Don't include libgcc anymore" (70163a381f1a5c93fcc181365cdb092566d8c5c5) without compile errors.
It's not controversial. It has been formally NAKed and rejected. It is not needed as working fixes are already available in mainline.
Best regards,
Wolfgang Denk
Dear Ulf Samuelsson,
In message 4A810DBC.50805@atmel.com you wrote:
When trying to build U-Boot under Buildroot and OpenEmbedded,
These probably count to the tool chains with "broken" ARM cross compilers.
When linking u-boot the linker seems to use the div0 from the C compiler libgcc instead of the u-boot div0.
Try setting USE_PRIVATE_LIBGCC=yes in your envrionment, like
USE_PRIVATE_LIBGCC=yes make ...
Best regards,
Wolfgang Denk
Wolfgang Denk skrev:
Dear Ulf Samuelsson,
In message 4A810DBC.50805@atmel.com you wrote:
When trying to build U-Boot under Buildroot and OpenEmbedded,
These probably count to the tool chains with "broken" ARM cross compilers.
Maybe, Buildroot is even more broken, if you try to use an external toolchain and I would be surprised if openembedded is better. In the end, noone wants to mess around with one compiler per application so it is better if a small fix to u-boot can be applied.
When linking u-boot the linker seems to use the div0 from the C compiler libgcc instead of the u-boot div0.
Try setting USE_PRIVATE_LIBGCC=yes in your envrionment, like
USE_PRIVATE_LIBGCC=yes make ...
I have done two fixes to make it build with openembedded. 1) Define "raise" in libarm/board.c which calls hang. 2) Changes mapi to "-mapi=aapcs-linux" in cpu/arm926ej-s/config.mk Some toolchains want to keep apcs-gnu I guess.
Best regards,
Wolfgang Denk
BR Ulf Samuelsson
Dear Ulf Samuelsson,
In message 4A81E724.3070205@atmel.com you wrote:
Try setting USE_PRIVATE_LIBGCC=yes in your envrionment, like
USE_PRIVATE_LIBGCC=yes make ...
I have done two fixes to make it build with openembedded.
- Define "raise" in libarm/board.c which calls hang.
Did you use "USE_PRIVATE_LIBGCC=yes", and it still needed raise(), or did you implement that workaround instead of using "USE_PRIVATE_LIBGCC=yes".
Normally no raise() should be needed when using USE_PRIVATE_LIBGCC=yes
- Changes mapi to "-mapi=aapcs-linux" in cpu/arm926ej-s/config.mk Some toolchains want to keep apcs-gnu I guess.
I wonder why we enforce a specific API at all - would it not be better to use the toolchain provided default settings?
Best regards,
Wolfgang Denk
Sent: Tuesday, August 11, 2009 11:58 PM Subject: Re: [U-Boot] "raise" not defined, when compiler uses its own div0
Dear Ulf Samuelsson,
In message 4A81E724.3070205@atmel.com you wrote:
Try setting USE_PRIVATE_LIBGCC=yes in your envrionment, like
USE_PRIVATE_LIBGCC=yes make ...
I have done two fixes to make it build with openembedded.
- Define "raise" in libarm/board.c which calls hang.
Did you use "USE_PRIVATE_LIBGCC=yes", and it still needed raise(), or did you implement that workaround instead of using "USE_PRIVATE_LIBGCC=yes".
Normally no raise() should be needed when using USE_PRIVATE_LIBGCC=yes
Instead, since I think it is ugly. If I build u-boot from the u-boot dir outside the buildsystem, it also means a lot of typing - If I remember to do it...
Why not make it a default mode? Then there is no problem anywhere and the patch is not needed.
- Changes mapi to "-mapi=aapcs-linux" in cpu/arm926ej-s/config.mk Some toolchains want to keep apcs-gnu I guess.
I wonder why we enforce a specific API at all - would it not be better to use the toolchain provided default settings?
I tried that, but that did not work with openembedded. ' I suspect that the openembedded libraries are built with -mapi-aapcs-linux. -mapi=apcs-gnu is not a problem with buildroot.
A similar thing: For ARM, "-msoftfloat" is enforced, and I think that should be removed. AFAIK there are no floating point stuff in u-boot, and why then enforce something which might or might not work for an arbitrary toolchain.
Is there any toolchain that will not work, if -msoftfloat is removed?
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Single tasking: Just Say No.
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Dear "Ulf Samuelsson",
In message E26FF1FBF0834320AC6F19CE783C7E69@aeglos you wrote:
If I build u-boot from the u-boot dir outside the buildsystem, it also means a lot of typing - If I remember to do it...
Why not make it a default mode?
Because the default mode is to assume you are using a "good" tool chain.
Best regards,
Wolfgang Denk
On Wednesday 12 August 2009 08:04:40 Wolfgang Denk wrote:
Ulf Samuelsson wrote:
If I build u-boot from the u-boot dir outside the buildsystem, it also means a lot of typing - If I remember to do it...
Why not make it a default mode?
Because the default mode is to assume you are using a "good" tool chain.
considering these "broken" toolchains are merely following upstream gcc behavior, the definition of "good" will quickly become synonymous with "old" if it hasnt already. while the situation does blow, might as well accept reality and make the local one the default. -mike
participants (4)
-
Gaye Abdoulaye Walsimou -
Mike Frysinger -
Ulf Samuelsson -
Wolfgang Denk