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

[Albert ARIBAUD]

Hello Tom,

On Sun, 27 Mar 2016 09:36:41 -0400, Tom Rini  wrote:
> On Fri, Mar 25, 2016 at 07:37:25AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> > 
> > On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini  wrote:
> > > On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > > > Hello Tom,
> > > > 
> > > > On Wed, 23 Mar 2016 17:36:17 -0400, 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  
> > > > > > 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  
> > > > > > > > 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
> > > > 
> > > > (ok, that explains what you mean by AEABI functions -- those are
> > > > actually not functions defined by the AEABI, but functions that the GCC
> > > > folks prefixed with __aeabi.)
> > > 
> > > No.  For reference,
> > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> > > and chapter 4 is all about the support library.  We are entirely in our
> > > right to do either of (a) use the compiler-provided library (b) provide
> > > our own implementation of what we need.  The kernel opts for (b) and I
> > > would like us to follow that as well, consistently, rather than ad-hoc.
> > 
> > Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
> > meant AEABI itself.
> > 
> > But then what you seek is is not a custom libgcc; it is controlled
> > AEABI support library.
> 
> No.  It's not libgcc.  We call it libgcc, but we shouldn't.  We should
> call it lib1funcs which is part of the end result of Marek's patches.
> LLVM has its own library which does this.  But it's not about LLVM,
> either.

Well then, I don't know which lib the patch is about. AFAIK, libgcc is
described in https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html (which is
part of "GCC internals") as follows:

"GCC provides a low-level runtime library, libgcc.a or
libgcc_s.so.1 on some platforms. GCC 

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

[Tom Rini]

On Fri, Mar 25, 2016 at 07:37:25AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
> 
> On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini  wrote:
> > On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > > Hello Tom,
> > > 
> > > On Wed, 23 Mar 2016 17:36:17 -0400, 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  
> > > > > 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  
> > > > > > > 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
> > > 
> > > (ok, that explains what you mean by AEABI functions -- those are
> > > actually not functions defined by the AEABI, but functions that the GCC
> > > folks prefixed with __aeabi.)
> > 
> > No.  For reference,
> > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> > and chapter 4 is all about the support library.  We are entirely in our
> > right to do either of (a) use the compiler-provided library (b) provide
> > our own implementation of what we need.  The kernel opts for (b) and I
> > would like us to follow that as well, consistently, rather than ad-hoc.
> 
> Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
> meant AEABI itself.
> 
> But then what you seek is is not a custom libgcc; it is controlled
> AEABI support library.

No.  It's not libgcc.  We call it libgcc, but we shouldn't.  We should
call it lib1funcs which is part of the end result of Marek's patches.
LLVM has its own library which does this.  But it's not about LLVM,
either.

> I'm fine with that, since, contrary to libgcc, it has an external,
> stable, definition.
> 
> But that is *unrelated* to libgcc, which is not described nor intended
> as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
> and provides AEABI in the ARM case by accident -- or, more to the point,
> by sub-optimal design IMO.

Yes, "libgcc" often, but not always, is how U-Boot provides the
architecture specific compiler support library functions.  Or rather,
ARM and PowerPC are the big cases where we rely on -lgcc and everywhere
else simply provides the required 

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

[Albert ARIBAUD]

On Fri, 25 Mar 2016 07:37:25 +0100, Albert ARIBAUD
 wrote:
> Hello Tom,

> That way,
> 
> 0) U-Boot gets the stable and controlled AEABI support you want;
> 
> 1) GCC keeps its somewhat stable but uncontrolled internal "generated
>code / libgcc" interface;
> 
> 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
>i.e. whatever ibgcc-related but non-AEABI-related changes occur in
>a GCC release, we won't break them changes in non-AEABI ;
> 
> 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
>breakages happen in a given GCC toolchain will not break U-Boot.
> 
> 4) This design works with any ARM toolchain -- which is kind of evident
>since it separates generic ARM EABI support from specific toolchain
>support.

Addition: this does not mean we should get rid of the private libgcc
support: it can be useful in case of an issue with the non-aeabi part
of libgcc.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hello Sergey,

On Thu, 24 Mar 2016 18:37:52 -0700 (PDT), Sergey Kubushyn
 wrote:
> On Thu, 24 Mar 2016, Tom Rini wrote:

> U-Boot is a standalone program not supposed to coexist with any external
> applications i.e. it is totally self-sufficient, not living in some kind of
> system environment so it makes perfect sense for it not to use _ANY_
> external parts in the final binary.

Granted U-Boot is standalone as a binary system component, but this
binary, as the produce of GCC, is dependent on libgcc for more than
simply AEABI support, hence my proposal.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hello Tom,

On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini  wrote:
> On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> > 
> > On Wed, 23 Mar 2016 17:36:17 -0400, 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  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  
> > > > > > 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
> > 
> > (ok, that explains what you mean by AEABI functions -- those are
> > actually not functions defined by the AEABI, but functions that the GCC
> > folks prefixed with __aeabi.)
> 
> No.  For reference,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> and chapter 4 is all about the support library.  We are entirely in our
> right to do either of (a) use the compiler-provided library (b) provide
> our own implementation of what we need.  The kernel opts for (b) and I
> would like us to follow that as well, consistently, rather than ad-hoc.

Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
meant AEABI itself.

But then what you seek is is not a custom libgcc; it is controlled
AEABI support library.

I'm fine with that, since, contrary to libgcc, it has an external,
stable, definition.

But that is *unrelated* to libgcc, which is not described nor intended
as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
and provides AEABI in the ARM case by accident -- or, more to the point,
by sub-optimal design IMO.

The right design for solving the problems raised by Marek is therefore
to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
and link U-Boot *first* against this AEABI support library, *then*
against GCC's libgcc.

Essentially, this 'hijacks' whatever is AEABI from libgcc while not
interfering with what is not AEABI (i.e. what is purely GCC/libgcc
internals).

That way,

0) U-Boot gets the stable and controlled AEABI support you want;

1) GCC keeps its somewhat stable but uncontrolled internal "generated
   code / libgcc" interface;

2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
   i.e. whatever ibgcc-related but non-AEABI-related changes occur in
   a GCC release, we won't break them 

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

[Sergey Kubushyn]

On Thu, 24 Mar 2016, Tom Rini wrote:


On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, 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  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  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


(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)


No.  For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library.  We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need.  The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.


Second that. By having _EVERYTHING_ coming from U-Boot we are taking care of
_ANY_ possible mismatch between what we are building and pre-built toolchain
libraries. Soft float in ARM U-Boot and VFP hard float in most i.MX6/7
toolchains is just one of such prominent examples.

U-Boot is a standalone program not supposed to coexist with any external
applications i.e. it is totally self-sufficient, not living in some kind of
system environment so it makes perfect sense for it not to use _ANY_
external parts in the final binary.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
> 
> On Wed, 23 Mar 2016 17:36:17 -0400, 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  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  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
> 
> (ok, that explains what you mean by AEABI functions -- those are
> actually not functions defined by the AEABI, but functions that the GCC
> folks prefixed with __aeabi.)

No.  For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library.  We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need.  The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Sergey Kubushyn]

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

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

 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 

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

[Marek Vasut]

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

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

[Sergey Kubushyn]

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

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

 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 

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

[Marek Vasut]

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

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

[Sergey Kubushyn]

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

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

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

> > 

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

[Sergey Kubushyn]

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

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 17:36:17 -0400, 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  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  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

(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)

I do understand that clang does not provide these functions. What I
want to understand is how come code compiled by clang would need them
unless we introduced that dependency ourselves. clang does produce
correct and self-sufficient code when using 64-bit division, right?

> > > > Also, libgcc is not a standalone project that can be frozen, forked or
> > > > improved freely; it is an internal component of the GCC toolchain. No
> > > > standard defines what libgcc is or should be, and we have no control
> > > > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > > > project may decide to change that contract at any time, and produce a
> > > > new toolchain and a new libgcc. Using our private libgcc by default
> > > > will cause all targets to break for no good reason. We've already been
> > > > bitten by internal GCC changes on which we were dependent; adding more
> > > > such dependency is not the way to go IMO.
> > > > 
> > > > If we truly fear that GCC is *generally* unable to properly build our
> > > > targets due to its libgcc, then we should not only "snapshot and fix"
> > > > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > > > sure we keep a consistent copy of it. I don't think that would be a
> > > > viable move.
> > > > 
> > > > And if we don't believe that GCC is generally unable to properly build
> > > > U-Boot, then we should always use it as provided unless it is provably
> > > > buggy, in which case if a private libgcc is a fix, then by all means we
> > > > should use it.
> > > > 
> > > > And whenever we find that a GCC toolchain is provably buggy, we should
> > > > raise a bug, either to the toolchain provider if the issue is only with
> > > > a given binary release (e.g. mismatched or badly supported endianness),
> > > > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > > > of non-supported opcodes for a given arch/cpu).
> > > 
> > > Ah, but this shows part of the problem.  We don't need "libgcc" as in
> > > "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> > > which provides AEABI functions".
> > 
> > Not sure I'm getting what you mean. For one thing, I don't see that
> > AEABI specifies any 

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

[Sergey Kubushyn]

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


Will do first thing tomorrow morning when I'm back at my work desk. Will
post the results when done.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

On 03/24/2016 01:13 AM, Tom Rini wrote:
> On Thu, Mar 24, 2016 at 12:49:54AM +0100, 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 
 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 
>> 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 ?
> 
> Follow-up _series_ to re-sync our 64bit math stuff with the kernel.
> 
Something tells me this is gonna be one patch , not a series.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Thu, Mar 24, 2016 at 12:49:54AM +0100, 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 
> >> 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 
>  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 ?

Follow-up _series_ to re-sync our 64bit math stuff with the kernel.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

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

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Sergey Kubushyn]

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 
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 
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 :)

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

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

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Sergey Kubushyn]

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

The target is a custom board based on Freescale/NXP mx6qsabresd (I'm not
ready to submit it to the main tree yet) so sabresd should produce the same
result. Just have IPU enabled.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Sergey Kubushyn]

On Wed, 23 Mar 2016, 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  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  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?


It is. However do_div does not help for some reason -- here is an excerpt
from drivers/video/ipu_common.c (one of several places where do_div() is
used) that pulls _udivmoddi4 from toolchain anyways:

=== Cut ===
static void ipu_pixel_clk_recalc(struct clk *clk)
{
u32 div;
u64 final_rate = (unsigned long long)clk->parent->rate * 16;

div = __raw_readl(DI_BS_CLKGEN0(clk->id));
debug("read BS_CLKGEN0 div:%d, final_rate:%lld, prate:%ld\n",
  div, final_rate, clk->parent->rate);

clk->rate = 0;
if (div != 0) {
do_div(final_rate, div);
clk->rate = final_rate;
}
}
=== Cut ===

Without the above hack this results in link failure:

=== Cut ===
arm-linux-gnueabi-ld.bfd: error: 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
 uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file 
/opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===

U-Boot built with "-mfloat-abi=hard -mfpu=vfpv3-d16" pulls whatever it
requires from toolchain libgcc and works fine, no problems.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

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

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

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

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Sergey Kubushyn]

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

The problem is most of i.MX6 toolchains (including my own) are built with
"-mfloat-abi=hard -mfpu=vfpv3-d16" or something similar so it fails to link
with the rest of U-Boot that is unconditionally built with "-msoft-float"
for unknown reason.

We should either add 64-bit functions to private libgcc so it is built and
linked properly with whatever ABI are nailed down in arch/arm/config.mk or
somehow allow to specify specific ABI flags in board configuration or
wherever else.

I do use a hack like this

=== Cut ===
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 9af6c37..a96868c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,8 +16,14 @@ endif
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
 -fno-common -ffixed-r9
-PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
-  $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
+
+ifeq ($(CONFIG_SYS_HARDFP_VFP_BUILD),y)
+PLATFORM_RELFLAGS += $(call cc-option,-mfloat-abi=hard,$(call 
cc-option,-mfpu=vfpv3-d16,))
+else
+PLATFORM_RELFLAGS += $(call cc-option, -msoft-float)
+endif
+
+PLATFORM_RELFLAGS += $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
=== Cut ===

but this is not very nice so it won't go in the main tree for sure.

A smarter, more elegant way should be invented so the entire U-Boot could be
built with ABI flags matched those used for toolchain build.

Or _ALL_ libgcc functions should be made U-Boot private so no toolchain
parts are used at all.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

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

> > > Also, libgcc is not a standalone project that can be frozen, forked or
> > > improved freely; it is an internal component of the GCC toolchain. No
> > > standard defines what libgcc is or should be, and we have no control
> > > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > > project may decide to change that contract at any time, and produce a
> > > new toolchain and a new libgcc. Using our private libgcc by default
> > > will cause all targets to break for no good reason. We've already been
> > > bitten by internal GCC changes on which we were dependent; adding more
> > > such dependency is not the way to go IMO.
> > > 
> > > If we truly fear that GCC is *generally* unable to properly build our
> > > targets due to its libgcc, then we should not only "snapshot and fix"
> > > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > > sure we keep a consistent copy of it. I don't think that would be a
> > > viable move.
> > > 
> > > And if we don't believe that GCC is generally unable to properly build
> > > U-Boot, then we should always use it as provided unless it is provably
> > > buggy, in which case if a private libgcc is a fix, then by all means we
> > > should use it.
> > > 
> > > And whenever we find that a GCC toolchain is provably buggy, we should
> > > raise a bug, either to the toolchain provider if the issue is only with
> > > a given binary release (e.g. mismatched or badly supported endianness),
> > > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > > of non-supported opcodes for a given arch/cpu).
> > 
> > Ah, but this shows part of the problem.  We don't need "libgcc" as in
> > "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> > which provides AEABI functions".
> 
> Not sure I'm getting what you mean. For one thing, I don't see that
> AEABI specifies any functions. Also, I don't see where it is established
> that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
> is a standalone project aiming at providing AEABI functions.

Well, lets unpack things in the order that it matters.  If we kludge the
toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in
libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start
failing on:
arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
undefined reference to `__aeabi_uidiv'
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
undefined reference to `__aeabi_uidiv'

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

[Albert ARIBAUD]

Hello Tom,

On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini  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  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?

> > Also, libgcc is not a standalone project that can be frozen, forked or
> > improved freely; it is an internal component of the GCC toolchain. No
> > standard defines what libgcc is or should be, and we have no control
> > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > project may decide to change that contract at any time, and produce a
> > new toolchain and a new libgcc. Using our private libgcc by default
> > will cause all targets to break for no good reason. We've already been
> > bitten by internal GCC changes on which we were dependent; adding more
> > such dependency is not the way to go IMO.
> > 
> > If we truly fear that GCC is *generally* unable to properly build our
> > targets due to its libgcc, then we should not only "snapshot and fix"
> > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > sure we keep a consistent copy of it. I don't think that would be a
> > viable move.
> > 
> > And if we don't believe that GCC is generally unable to properly build
> > U-Boot, then we should always use it as provided unless it is provably
> > buggy, in which case if a private libgcc is a fix, then by all means we
> > should use it.
> > 
> > And whenever we find that a GCC toolchain is provably buggy, we should
> > raise a bug, either to the toolchain provider if the issue is only with
> > a given binary release (e.g. mismatched or badly supported endianness),
> > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > of non-supported opcodes for a given arch/cpu).
> 
> Ah, but this shows part of the problem.  We don't need "libgcc" as in
> "the thing which provides gcc'isms".  We need "libgcc" as in "the thing
> which provides AEABI functions".

Not sure I'm getting what you mean. For one thing, I don't see that
AEABI specifies any functions. Also, I don't see where it is established
that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
is a standalone project aiming at providing AEABI functions.

> Today we get these from libgcc but we
> run into cases where this doesn't work quite right (toolchain fun) or
> simply aren't available (again, clang).  So I am in favour of re-syncing
> with this part of the kernel and mirroring the decision to always
> include these functions, again, like the kernel does.

If we are using libgcc for providing AEABI services then we are using it
wrong. Its role is to support GCC-generated code.

Could you give me an example of this "need for [an] AEABI function"?

> -- 
> Tom

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

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

> Also, libgcc is not a standalone project that can be frozen, forked or
> improved freely; it is an internal component of the GCC toolchain. No
> standard defines what libgcc is or should be, and we have no control
> over the 'contract' between GCC-emitted code and libgcc. The GCC
> project may decide to change that contract at any time, and produce a
> new toolchain and a new libgcc. Using our private libgcc by default
> will cause all targets to break for no good reason. We've already been
> bitten by internal GCC changes on which we were dependent; adding more
> such dependency is not the way to go IMO.
> 
> If we truly fear that GCC is *generally* unable to properly build our
> targets due to its libgcc, then we should not only "snapshot and fix"
> libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> sure we keep a consistent copy of it. I don't think that would be a
> viable move.
> 
> And if we don't believe that GCC is generally unable to properly build
> U-Boot, then we should always use it as provided unless it is provably
> buggy, in which case if a private libgcc is a fix, then by all means we
> should use it.
> 
> And whenever we find that a GCC toolchain is provably buggy, we should
> raise a bug, either to the toolchain provider if the issue is only with
> a given binary release (e.g. mismatched or badly supported endianness),
> or to the GCC project if the bug is inherent to GCC (e.g. generation
> of non-supported opcodes for a given arch/cpu).

Ah, but this shows part of the problem.  We don't need "libgcc" as in
"the thing which provides gcc'isms".  We need "libgcc" as in "the thing
which provides AEABI functions".  Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or
simply aren't available (again, clang).  So I am in favour of re-syncing
with this part of the kernel and mirroring the decision to always
include these functions, again, like the kernel does.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Albert ARIBAUD]

Hello Marek,

On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut  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. 

Also, libgcc is not a standalone project that can be frozen, forked or
improved freely; it is an internal component of the GCC toolchain. No
standard defines what libgcc is or should be, and we have no control
over the 'contract' between GCC-emitted code and libgcc. The GCC
project may decide to change that contract at any time, and produce a
new toolchain and a new libgcc. Using our private libgcc by default
will cause all targets to break for no good reason. We've already been
bitten by internal GCC changes on which we were dependent; adding more
such dependency is not the way to go IMO.

If we truly fear that GCC is *generally* unable to properly build our
targets due to its libgcc, then we should not only "snapshot and fix"
libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
sure we keep a consistent copy of it. I don't think that would be a
viable move.

And if we don't believe that GCC is generally unable to properly build
U-Boot, then we should always use it as provided unless it is provably
buggy, in which case if a private libgcc is a fix, then by all means we
should use it.

And whenever we find that a GCC toolchain is provably buggy, we should
raise a bug, either to the toolchain provider if the issue is only with
a given binary release (e.g. mismatched or badly supported endianness),
or to the GCC project if the bug is inherent to GCC (e.g. generation
of non-supported opcodes for a given arch/cpu).

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot