[U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
Sergey Kubushyn
ksi at koi8.net
Thu Mar 24 23:25:00 CET 2016
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 08:08 PM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
>>>> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>>>>
>>>>> 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.
>>>>
>>>> OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private
>>>> libgcc,
>>>> my bad -- thought it would be automatic. Having that defined makes build
>>>> fail complaining about assembly syntax in div64.S:
>>>>
>>>> === Cut ===
>>>> arch/arm/lib/div64.S: Assembler messages:
>>>> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl
>>>> ip)'
>>>> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
>>>> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
>>>> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o'
>>>> failed
>>>> make[1]: *** [arch/arm/lib/div64.o] Error 1
>>>> Makefile:1214: recipe for target 'arch/arm/lib' failed
>>>> make: *** [arch/arm/lib] Error 2
>>>> === Cut ===
>>>>
>>>> Probably something is missing in div64.h? The Linux one is totally
>>>> different. Digging in right now...
>>>
>>> Are you building the stuff with all of these 5+1 patches ?
>>
>> Nope. Aren't those already in U-Boot master? I pulled the latest master and
>> thought those were there. If not would you please send me those 5
>> patches so
>> I wouldn't have to hunt them through archives?
>
> I'll send you all six off-list.
OK, it worked. Now it is time to push it into the official tree :)
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
More information about the U-Boot
mailing list