On Wed, Oct 6, 2010 at 11:23 AM, John Rigby john.rigby@linaro.org wrote:

Thanks Michael.  Just wanted to make sure I understood.  The "do no harm" goal and the Thumb2 libgcc seem to be somewhat contradictory however.  I realize that choices need to be made and only odd ducks like me will likely run into issues.

I'd like to use our toolchain on my N800 and Cortex-M3 boards as well. The 'do no harm' is at the source level - you should be able to take the Linaro GCC tarball and build a compiler for your particular situation that is as good as and probably more correct than the FSF GCC. Unfortunately we can't make one libgcc that covers all ARM products as some like the Cortex-M series are Thumb-2 only, some like the Cortex-M0 are Thumb-1 only, and some (very old ones) are ARM only. Then you add the floating point options into the mix.

It would be nice to ship multiple builds of libgcc with the cross compiler but that's currently out of scope.

-- Michael

On Wednesday 06 October 2010, Steve Langasek wrote:

It sounds like what you need for this is a multilib-enabled armel compiler build, that includes a libgcc build for ARMv7 as well as separate libgcc builds for whichever other ARM targets you're after. You should coordinate this with Marcin (cc:ed), who can help with the toolchain packaging details for either a native or cross- compiler.

The question is how far we want to go, since a real multilib toolchain would require multilib-versions of not only libgcc but also (at least) glibc and libstdc++.

The linaro toolchain is currently very much usable to build a pre-v7 kernel and anything that uses -ffreestanding, and IMHO we should try to keep it that way.

Would there be anything that we might want to build besides u-boot that requires an matching libgcc but not also an matching glibc?

Arnd

I'm really sorry to have started this, but for completeness here is the rest of the story. 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.

The naive magical solution would be to for the linker to understand the -march="old non Thumb-2 ARM" and flag an error when linking with a Thumb-2 libgcc.a. Even better would be for the toolchain to have multiple libgcc's and use the right one.

The answer is that the developer just needs to know that the libgcc in the Linaro toolchain is Thumb-2 so they must use the libgcc included in the u-boot source when building for old ARM targets.

Again, sorry for injecting this noise. My question is answered.

John

On Wed, Oct 6, 2010 at 6:41 AM, Loïc Minier loic.minier@linaro.org wrote:

On Tue, Oct 05, 2010, Steve Langasek wrote:

...

OOI, what are the U-Boot targets you're looking to build for that don't support ARMv7?  A gcc multilib package for armel will be easy to implement but hard to maintain, and certainly none of the systems Linaro is targeting should require a pre-Thumb-2 U-Boot, so I'm very doubtful that the ongoing effort to maintain such a toolchain in Ubuntu is justified (unless we find that it becomes substantially easier with multiarch, I guess, but we're a ways away from that yet).

Isn't Thumb 2 the actual issue here?  U-Boot is built with -marm; does  it cause any issue to mix with our Thumb-2 libgcc?

-- Loďc Minier

On 06/10/10 15:48, Loïc Minier wrote:

On Wed, Oct 06, 2010, John Rigby wrote:

...

                     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.

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

On 07/10/10 12:36, Matthias Klose wrote:

last time I checked this "multilibs" feature was implemented by building the toolchain N times. By which magic is the correct library selected? I didn't find anything in fsf trunk which supports this kind of multilibs builds.

It's there, and has been since forever. :)

You pass --enable-multilibs when you configure the compiler, and you get all the libgcc.a, crt[in].o, and other such files compiled and installed automatically. If you build for bare-metal, and newlib is in your source tree, that gets built automatically also. I think glibc has to be built multiple times manually.

The compiler selects the libraries by recognising the compiler command line switches and matching them to a library. It then adjusts the search paths accordingly.

If you do "gcc -print-multi-lib" on Ubuntu gcc (Lucid) it says:

.; 32;@m32

This means there are two multilibs: the first has libraries found in directory "." (i.e. the root of the library directory) and is used for the default options (there's a blank after the ";"); and the second has libraries in the directory "32" and is used whenever the -m32 option is passed.

Andrew

On 07/10/10 13:08, Matthias Klose wrote:

they must have renamed that recently from --enable-multilib ;)

Sneaky bunch, those GCC maintainers!

right, the multilib options are in t-arm-elf, not in t-linux-armeabi. The old t-linux has the ones for hard/softfp commented out.

Right, Linux compilers don't typically have much use for multilibs - you know what your configuration is and stick with it.

The the 32/64 bit multilibs exist, of course, but they don't change the architecture settings, and they're "special", in that the libraries are typically installed outside the usual scheme.

Andrew

Hi,

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.

Basically the bare-metal situation is just another ABI which could potentially have its own libgcc variant(s) etc, in a similar way to the float-abi issues. libgcc is truly a special case here, because it's needed for the compiler to implement the C language, and so hard not to depend on it even if avoiding all other libraries. Is it worth thinking about how to add this ABI-variant capability to multilibs?

This may be an oversimplification of the situation though, and there are still questions about whether this makes sense, and whether enough people care.

However, just from consistency arguments, I think that if we were to have problems build linaro U-Boot with the linaro toolchain that would be a bad thing (though if I've understood correctly, we have workarounds for this which are valid provided that linaro-supported, i.e. v7-A+, hardware is targeted. The thumb2 libgcc is exposing problems in U-Boot, not gcc/binutils in this case)

Cheers ---Dave

On Thu, 7 Oct 2010, Andrew Stubbs wrote:

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.

The kernel does indeed explicitly avoid any linkage with libgcc.a. It is self contained and provide its own set of equivalent functions typically carried by libgcc.a, and explicitly _exclude_ some other functions (such as 64-bit divisions) to ensure they're never used in the kernel.

I strongly suggest you use a bare-metal compiler configured for the right architecture(s), such as CodeSourcery's ARM EABI Lite toolchain.

I think that a perfectly valid alternative is for the bare-metal target program to provide its own support library as the kernel does. So if U-Boot already comes with its own libgcc.a equivalent, then it should just be used.

Nicolas

On 07/10/10 12:03, Wookey wrote:

gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than that. (i.e if you ask for v5, v6, v7, vfp, and neon options you get 25 versions of libgcc1, most of which are silly combinations)

It's not really the implementation that gives the "combinatorial explosion", so much as the problem.

E.g. Say you want enough libraries to be able to build for: * ARM mode or Thumb mode, * with FP, or without, and * both big endian and little endian.

That's 8 different libraries: 1. ARM FP LE 2. ARM FP BE 3. ARM noFP LE 4. ARM noFP BE 5. Thumb FP LE 6. Thumb FP BE 7. Thumb noFP LE 8. Thumb noFP BE

Joseph Myers of Codesourcery has been looking at making this into a more flexible mechanism where you just choose the combinations you actually cared about, not every possible one. I hope that the output of that work would mean we (or someone else like Debian) could choose to support a couple of other useful options, and maybe even a nice runtime way of selecting them.

SuperH already has this. When you build the toolchain you can choose exactly what multilibs will be available with a few configuration options. Other architectures only let you choose what the default will be, and whether to build all the multilibs or not.

CodeSourcery limits the number of multilibs in our product builds by adding our own custom configuration files into the GCC sources, but these are hardly flexible.

All these solutions still require pre-baking the decision into the toolchain.

A possible solution to the problem would be to include the sources to libgcc.a in the installation, and teach gcc to compile it on-the-fly, as necessary. Obviously, you'd still want to pre-bake the most commonly used configuration, for performance reasons. This wouldn't work for libgcc.so, but you probably wouldn't want it to ...

Andrew

On 07/10/10 12:54, arnd@arndb.de wrote:

On Thursday 07 October 2010 13:03:14 Wookey wrote:

...

gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than that. (i.e if you ask for v5, v6, v7, vfp, and neon options you get 25 versions of libgcc1, most of which are silly combinations)

If I understood Uli correctly, you can have one version of libgcc that is used as the fallback in a multilib setup, and most variants are backwards compatible.

Yes, with some carefully thought out custom configuration patches we can certainly do something like what you suggest.

You can tell GCC exactly what arches you want multilibs for, and what options (neon, vfp, etc) you want multilibs for, and it will automatically fill in the N-dimensional matrix that gives you all those options.

Like Wookey said, this can produce a selection of pointless libraries that either make no sense, or else are duplicates of other libraries, so GCC has ways to deal with this:

1. You can disable any specific option combination you like.

2. You can specify that one set of options should use the library from another, compatible set of options.

3. You can add custom "specs" rules that tell it what to do in the "fall back" case (normal procedure is to use the default library - the primary target for the toolchain, but in this case, we're talking about having a fall-back to a lowest-common-denominator library, which would be far less optimal).

All this can be done with a small patch to two or three files. It's quite easy, but we just need to know what it is we want to achieve. Any such patch should be done in a way that plays nice with other people requirements for building the sources, and even then would probably not be acceptable upstream.

Although these things *can* be done, I'm really not sure that they *should*. As has been pointed out already, this use case really is an abuse of a Linux user-space compiler, and will add features that 99.99% of users will never care about, yet will increase both the build and test burden for developers/packagers all the time, possibly considerably.

Andrew