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

Sergey Kubushyn ksi at koi8.net
Thu Mar 24 19:43:42 CET 2016


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

---
******************************************************************
*  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