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

[Marek Vasut]

On 03/24/2016 01:13 AM, Tom Rini wrote:
> 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.
> 
Something tells me this is gonna be one patch , not a series.

-- 
Best regards,
Marek Vasut