[U-Boot] [PATCH 5/5] lib: Enable private libgcc by default

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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,
-- 
Albert.