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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
