[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:54 AM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, 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 ?
>>
>> Sure I'll test it, no problems. Just bake the patch :)
>
> Done, give it a go please.

OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.

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