On 06/10/10 15:48, Loïc Minier wrote:
On Wed, Oct 06, 2010, John Rigby wrote:
The hypothetical scenario is a developer thatmaintains u-boot for multiple platforms. Using a codesourcery or eldk (from denx.de) toolchain one can use the appropriate -march= to get the right code from the compiler. Also the libgcc.a is ARM so all is well.
The CodeSourcery toolchain has "multilibs" to support this. That is, there is one copy of libgcc (and glibc/newlib/uclibc, depending on the SG++ you choose) per -march option. Other options (such as -mfloat and -marm/-mthumb, endian, etc) also have specialist libraries available.
Using a linaro toolchain using the same -march= you get the right code from the compiler but the result will get linked with a Thumb-2 libgcc.a and the resulting binary will not run on an older ARM.
The Linaro/Ubuntu binary releases are configured specifically for the architectures they are intended to run on. If you try to build for something else then you're not using the right tool for the job.
I would recommend either building a Linaro compiler from source, with the desired config, or else using a CodeSourcery compiler (the two are *very* closely related).
If however libgcc.a was ARM then it would just work.
This would work, but it doesn't really make much sense for the libgcc to be configured differently to the entire rest of the distribution (and you'd need to do some build system hackery to get gcc installed that way).
Again, I'm not saying this is a bug or even something for Linaro to care about. It just means that the Linaro toolchain is not something that this hypothetical u-boot maintainer would want to use as his/her one and only toolchain.
Agreed. You should use a compiler built for the job.
So it strikes me as a toolchain bug; if I understand what you're saying above:
- libgcc built with -march=armv7a can be used with ARMv4, v5, v6, v7 CPUs (if you pass the correct -march=), so it's backwards compatible even if libgcc is built with -march=armv7a
This statement is false. Code compiled with -march=armv7a will only run on ARMv7a or compatible. It's possible that simple programs might, by chance, work on older cores, but relying on this behaviour even there is just broken.
- libgcc built with -mthumb is NOT compatible with CPUs lacking thumb, even if you pass -marm
No, that's why multilibed compilers (such as CodeSourcery's) substitute a different libgcc when you use those options.
[snip]
Is it purely accidental that libgcc built for -march=armv7 works on older CPUs? Why can't this mechanism be extended to -marm/-mthumb and to VFP options?
See above. Some routines might work on some older hardware, by chance, but it's subject to change at any moment, and I doubt the entire library is backward compatible.
There's another issue here: using a Linux user-space compiler to build for bare-metal is a bad plan. libgcc is built assuming that system calls and exceptions etc. work as they do in Linux user-mode. The Linux kernel is built with a user-space compiler for convenience, but a) the kernel is always configured for the same hardware as the user-space, and b) it has it's own versions of (at least some of) the libgcc routines, customized for it's own environment.
I strongly suggest you use a bare-metal compiler configured for the right architecture(s), such as CodeSourcery's ARM EABI Lite toolchain.
Andrew