On Wed, Oct 06, 2010, John Rigby wrote:
I'm really sorry to have started this, but for completeness here is the rest of the story.
No need to be sorry, I think you're doing right to bring this up
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. 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. If however libgcc.a was ARM then it would just work. 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.
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 - libgcc built with -mthumb is NOT compatible with CPUs lacking thumb, even if you pass -marm
It gets a bit muddier if one considers that some armv7 CPUs could support Thumb-2 only, but these aren't ARMv7*A*, so I don't think that's relevant for the discussion.
I remember we had a similar case for a VFP libgcc back in jaunty, where doko had experienced a multilib VFP libgcc along the regular non-VFP libgcc.
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?