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

[Sergey Kubushyn]

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.

The target is a custom board based on Freescale/NXP mx6qsabresd (I'm not
ready to submit it to the main tree yet) so sabresd should produce the same
result. Just have IPU enabled.

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