[U-Boot-Users] Where can I find a libgcc.a with software FP.
Hi, all.
Where can I find a suitable u-boot compiler for ixp425? I once downloaded cross-compiler from ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain, and www.snapgear.com. They complain the similar issue as following. Mainly it is the libgcc.a did not support software FP. Can anybody give some info on this?
arm-linux-ld: ERROR: /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o) uses hardware FP, whereas u-boot uses software FP File in wrong format: failed to merge target specific data of file /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o)
In message 403B19CB.7040608@smartbridges.com you wrote:
Where can I find a suitable u-boot compiler for ixp425?
We use the ELDK. See http://www.denx.de/ELDK.html
Best regards,
Wolfgang Denk
On Tue, 24 Feb 2004, Bernieshu wrote:
Where can I find a suitable u-boot compiler for ixp425? I once downloaded cross-compiler from ftp://ftp.arm.linux.org.uk/pub/armlinux/toolchain, and www.snapgear.com. They complain the similar issue as following. Mainly it is the libgcc.a did not support software FP. Can anybody give some info on this?
arm-linux-ld: ERROR: /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o) uses hardware FP, whereas u-boot uses software FP File in wrong format: failed to merge target specific data of file /usr/local/lib/gcc-lib/arm-linux/3.3.2/be/libgcc.a(_udivsi3.o)
This is a problem with the gcc/binutils toochain, which doesn't handle -msoft-float the way we want it. The error you're seeing isn't really one, since neither the U-Boot code nor the quoted functions in libgcc.a actually use FP instructions. It's only the ELF binary tags that don't match.
If you remove the -msoft-float argument from U-Boot's Makefiles (that is, from the config.mk's) it should work. However, should your code ever generate floating point commands, there will be no compile error. U-Boot will simply crash in run-time, as there is no FP emulation handler running. I don't know to what extent this can happen, say, due to the compiler's optimisation attempts.
There are a number of patches for gcc 3.x floating around, which add proper -msoft-float to gcc. But since they also break binary compatibily (everything must be compiled anew) and seem to apply only for PXA, I'm not convinced those patches are really helpful.
Regards, Marius
In message Pine.LNX.4.56.0402241626510.21705@mag.sysgo.com Marius Groeger wrote:
This is a problem with the gcc/binutils toochain, which doesn't handle -msoft-float the way we want it. The error you're seeing isn't really one, since neither the U-Boot code nor the quoted functions in libgcc.a actually use FP instructions. It's only the ELF binary tags that don't match.
I'm not sure. I don't know for certain for ARM, but on other archi- tectures GCC will happily generate FP instructions for example to perform fast memory copy operations (like when assigning structures of the "right" size).
Best regards,
Wolfgang Denk
On Tue, 24 Feb 2004, Wolfgang Denk wrote:
In message Pine.LNX.4.56.0402241626510.21705@mag.sysgo.com Marius Groeger wrote:
This is a problem with the gcc/binutils toochain, which doesn't handle -msoft-float the way we want it. The error you're seeing isn't really one, since neither the U-Boot code nor the quoted functions in libgcc.a actually use FP instructions. It's only the ELF binary tags that don't match.
I'm not sure. I don't know for certain for ARM, but on other archi- tectures GCC will happily generate FP instructions for example to perform fast memory copy operations (like when assigning structures of the "right" size).
I'm having similar doubts, as I wrote in my previous post. Please read it again (to the end.)
In practice, however, I have not seen this kind of optimising as of yet. Maybe on ARM there is no gain in performance. Unless there is a proper (read: for all ARM architectures, and working like we know it from powerpc-linux) -msoft-float patch for GCC 3, I'm inclined to just (carefully) drop -msoft-float from *boot.
I'm curious about Robert Schwebel's assessment of this issue, since I know he's been workin on this.
Regards, Marius
participants (3)
-
Bernieshu -
Marius Groeger -
Wolfgang Denk