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

[Sergey Kubushyn]

On Wed, 23 Mar 2016, 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?

It is. However do_div does not help for some reason -- here is an excerpt
from drivers/video/ipu_common.c (one of several places where do_div() is
used) that pulls _udivmoddi4 from toolchain anyways:

=== Cut ===
static void ipu_pixel_clk_recalc(struct clk *clk)
{
         u32 div;
         u64 final_rate = (unsigned long long)clk->parent->rate * 16;

         div = __raw_readl(DI_BS_CLKGEN0(clk->id));
         debug("read BS_CLKGEN0 div:%d, final_rate:%lld, prate:%ld\n",
               div, final_rate, clk->parent->rate);

         clk->rate = 0;
         if (div != 0) {
                 do_div(final_rate, div);
                 clk->rate = final_rate;
         }
}
=== Cut ===

Without the above hack this results in link failure:

=== Cut ===
arm-linux-gnueabi-ld.bfd: error: /opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o) uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file /opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===

U-Boot built with "-mfloat-abi=hard -mfpu=vfpv3-d16" pulls whatever it
requires from toolchain libgcc and works fine, no problems.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************