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

[Marek Vasut <marex@denx.de>]

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@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@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.

Best regards,
Marek Vasut