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

[Tom Rini]

On Thu, Mar 24, 2016 at 12:49:54AM +0100, Marek Vasut wrote:
> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
> > On Thu, 24 Mar 2016, Marek Vasut wrote:
> > 
> >> On 03/24/2016 12:08 AM, Tom Rini wrote:
> >>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
> >>>> On Wed, 23 Mar 2016, Tom Rini 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
> >>>>
> >>>> There is also _udivmoddi4 pulled from libgcc for 64-bit division
> >>>> since we
> >>>> switched to 64-bit all around ARM. It comes from clock calculations for
> >>>> video, e.g. from drivers/video/ipu_common.c for i.MX6.
> >>>
> >>> Well, this is an example of why we both don't want libgcc ever nor do we
> >>> want to overly expand what we do offer.  In this case isn't it an
> >>> example of something that should be using lldiv/do_div/etc?
> >>
> >> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
> >> also doesn't implement the function. Which toolchain do you use and
> >> which target did you compile?
> > 
> > I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
> > Linux
> > arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
> > function that is used by do_div() from include/asm/div64.h for 32-bit ARM
> > platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
> > (that is totally different from what Linux provides) but no div64.S in
> > arch/arm/lib.
> 
> In that case, we should just import div64.S from Linux on arm32 and be
> done with it ? Since we now have all the necessary macros thanks to the
> first four patches in this series, that should be trivial.
> 
> What do you think? I can bake a patch real quick, so you can test it ?

Follow-up _series_ to re-sync our 64bit math stuff with the kernel.

-- 
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/87110bec/attachment.sig>