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 that > maintains 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? -- Loïc Minier _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
