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

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <trini at 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 at 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?

> > Also, libgcc is not a standalone project that can be frozen, forked or
> > improved freely; it is an internal component of the GCC toolchain. No
> > standard defines what libgcc is or should be, and we have no control
> > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > project may decide to change that contract at any time, and produce a
> > new toolchain and a new libgcc. Using our private libgcc by default
> > will cause all targets to break for no good reason. We've already been
> > bitten by internal GCC changes on which we were dependent; adding more
> > such dependency is not the way to go IMO.
> > 
> > If we truly fear that GCC is *generally* unable to properly build our
> > targets due to its libgcc, then we should not only "snapshot and fix"
> > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > sure we keep a consistent copy of it. I don't think that would be a
> > viable move.
> > 
> > And if we don't believe that GCC is generally unable to properly build
> > U-Boot, then we should always use it as provided unless it is provably
> > buggy, in which case if a private libgcc is a fix, then by all means we
> > should use it.
> > 
> > And whenever we find that a GCC toolchain is provably buggy, we should
> > raise a bug, either to the toolchain provider if the issue is only with
> > a given binary release (e.g. mismatched or badly supported endianness),
> > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > of non-supported opcodes for a given arch/cpu).
> 
> Ah, but this shows part of the problem.  We don't need "libgcc" as in
> "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> which provides AEABI functions".

Not sure I'm getting what you mean. For one thing, I don't see that
AEABI specifies any functions. Also, I don't see where it is established
that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
is a standalone project aiming at providing AEABI functions.

> Today we get these from libgcc but we
> run into cases where this doesn't work quite right (toolchain fun) or
> simply aren't available (again, clang).  So I am in favour of re-syncing
> with this part of the kernel and mirroring the decision to always
> include these functions, again, like the kernel does.

If we are using libgcc for providing AEABI services then we are using it
wrong. Its role is to support GCC-generated code.

Could you give me an example of this "need for [an] AEABI function"?

> -- 
> Tom

Amicalement,
-- 
Albert.