[U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
Sergey Kubushyn
ksi at koi8.net
Thu Mar 24 20:08:42 CET 2016
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?
---
******************************************************************
* 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