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

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini at 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 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?
> 
> 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.)

I do understand that clang does not provide these functions. What I
want to understand is how come code compiled by clang would need them
unless we introduced that dependency ourselves. clang does produce
correct and self-sufficient code when using 64-bit division, right?

> > > > 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.
> 
> Well, lets unpack things in the order that it matters.  If we kludge the
> toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in
> libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start
> failing on:

Here you are actively setting the conditions for the build to fail
since you prevent the linker from using *any* libgcc implentation
despite knowing that the generated code requires one.

> arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
> undefined reference to `__aeabi_uidiv'
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
> undefined reference to `__aeabi_uidiv'
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:66:
> undefined reference to `__aeabi_uidiv'
> and fail on and on from there (I see several pages).  Line 64-66 are:
>         printf("CPU clock:        %uMHz\n", get_hclk_pll_rate() / 1000000);
>         printf("AHB bus clock:    %uMHz\n", get_hclk_clk_rate() / 1000000);
>         printf("Peripheral clock: %uMHz\n", get_periph_clk_rate() / 1000000);
 
Do these errors occur when you do not actively prevent any libgcc from
linking? Do they occur when you do not prevent GCC's libgcc from linking?

> So, despite being "freestanding" and requring "no builtins" we still
> requiring the toolchain to give us these functions separately, or just
> bring them ourself.  Note that ARC, SH and MIPS all always follow the
> kernel model of just providing these bits of functionality rather than
> rely on getting just those things from libgcc.

Yes, we do require the toolchain to provide these functions, or more to
the point, we need to not prevent the toolchain from building our code
as it was designed to; and the toolchain was designed to generate code
which refers to symbols defined in a library that must be linked with
that code; and the toolchain provides that library as "libgcc". That is
exactly my point: the toolchain requires *and provides* libgcc. That's
an internal design-induced requirement, and users of the toolchain
should not even have to meddle with it unless broken.

Again, I an fine with private libgcc as a fix to specific case of
buggy toolchain releases. What I am not fine with is replacing a third
party tool's mechanism with our own when this mechanism works.

> > > 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"?
> 
> See above.  And yes, we're using libgcc wrong by IMHO using it at all.

And I think your view of what libgcc is is wrong. It is not something
*we* use, it is something that *GCC* uses by design. And it is not
something that we have a choice in using as long as we build with GCC.

> We don't need it and opt out of it for almost everything, except for the
> above.

We do need libgcc as long as we use GCC. The best proof is the
contrived build above, which you can reproduce with *any* GCC build,
cross or native, for bare metal code or for a Linux Hello World
application: when we actively deprive GCC from the libgcc that it
requires and provides, it won't work, exactly like when we remove gas
from a car, it won't run.

> -- 
> Tom



Amicalement,
-- 
Albert.