[U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
Marek Vasut
marex at denx.de
Thu Mar 24 20:04:41 CET 2016
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 ?
Best regards,
Marek Vasut
More information about the U-Boot
mailing list