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

[Tom Rini]

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.

> 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".  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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160323/60bbeb08/attachment.sig>