Hello Tom,
On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini trini@konsulko.com wrote:
On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
Hello Tom,
On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
Hello Tom,
On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini trini@konsulko.com wrote:
On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
Hello Marek,
On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut marex@denx.de wrote: > This patch decouples U-Boot binary from the toolchain on systems where > private libgcc is available. Instead of pulling in functions provided > by the libgcc from the toolchain, U-Boot will use it's own set of libgcc > functions. These functions are usually imported from Linux kernel, which > also uses it's own libgcc functions instead of the ones provided by the > toolchain. > > This patch solves a rather common problem. The toolchain can usually > generate code for many variants of target architecture and often even > different endianness. The libgcc on the other hand is usually compiled > for one particular configuration and the functions provided by it may > or may not be suited for use in U-Boot. This can manifest in two ways, > either the U-Boot fails to compile altogether and linker will complain > or, in the much worse case, the resulting U-Boot will build, but will > misbehave in very subtle and hard to debug ways.
I don't think using private libgcc by default is a good idea.
U-Boot's private libgcc is not a feature of U-Boot, but a fix for some cases where a target cannot properly link with the libgcc provided by the (specific release of the) GCC toolchain in use. Using private libgcc to other cases than these does not fix or improve anything; those other cases were working and did not require any fix in this respect.
This isn't true, exactly. If using clang for example everyone needs to enable this code. We're also using -fno-builtin -ffreestanding which should limit the amount of interference from the toolchain. And we get that.
You mean clang does not produce self-sustained binaries?
clang does not provide "libgcc", so there's no -lgcc providing all of the functions that are (today) in: _ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S _umodsi3.S div0.S _uldivmod.S which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
(ok, that explains what you mean by AEABI functions -- those are actually not functions defined by the AEABI, but functions that the GCC folks prefixed with __aeabi.)
No. For reference, http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf and chapter 4 is all about the support library. We are entirely in our right to do either of (a) use the compiler-provided library (b) provide our own implementation of what we need. The kernel opts for (b) and I would like us to follow that as well, consistently, rather than ad-hoc.
Kk, so you did not mean "whatever happens to be aeabi in libgcc, you meant AEABI itself.
But then what you seek is is not a custom libgcc; it is controlled AEABI support library.
I'm fine with that, since, contrary to libgcc, it has an external, stable, definition.
But that is *unrelated* to libgcc, which is not described nor intended as "AEABI support" -- libgcc exists in all architectures, even non-ARM, and provides AEABI in the ARM case by accident -- or, more to the point, by sub-optimal design IMO.
The right design for solving the problems raised by Marek is therefore to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library" and link U-Boot *first* against this AEABI support library, *then* against GCC's libgcc.
Essentially, this 'hijacks' whatever is AEABI from libgcc while not interfering with what is not AEABI (i.e. what is purely GCC/libgcc internals).
That way,
0) U-Boot gets the stable and controlled AEABI support you want;
1) GCC keeps its somewhat stable but uncontrolled internal "generated code / libgcc" interface;
2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc, i.e. whatever ibgcc-related but non-AEABI-related changes occur in a GCC release, we won't break them changes in non-AEABI ;
3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI breakages happen in a given GCC toolchain will not break U-Boot.
4) This design works with any ARM toolchain -- which is kind of evident since it separates generic ARM EABI support from specific toolchain support.
Comments welcome.
-- Tom
Amicalement,