Hello Tom, On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini <tr...@konsulko.com> 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 <tr...@konsulko.com> 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 <tr...@konsulko.com> wrote: > > > > > On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote: > > > > > > Hello Marek, > > > > > > > > > > > > On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de> > > > > > > wrote: > > > > > > > This patch decouples U-Boot binary from the toolchain on systems > > > > > > > where > > > > > > > private libgcc is available. Instead of pulling in functions > > > > > > > provided > > > > > > > by the libgcc from the toolchain, U-Boot will use it's own set of > > > > > > > libgcc > > > > > > > functions. These functions are usually imported from Linux > > > > > > > kernel, which > > > > > > > also uses it's own libgcc functions instead of the ones provided > > > > > > > by the > > > > > > > toolchain. > > > > > > > > > > > > > > This patch solves a rather common problem. The toolchain can > > > > > > > usually > > > > > > > generate code for many variants of target architecture and often > > > > > > > even > > > > > > > different endianness. The libgcc on the other hand is usually > > > > > > > compiled > > > > > > > for one particular configuration and the functions provided by it > > > > > > > may > > > > > > > or may not be suited for use in U-Boot. This can manifest in two > > > > > > > ways, > > > > > > > either the U-Boot fails to compile altogether and linker will > > > > > > > complain > > > > > > > or, in the much worse case, the resulting U-Boot will build, but > > > > > > > will > > > > > > > misbehave in very subtle and hard to debug ways. > > > > > > > > > > > > I don't think using private libgcc by default is a good idea. > > > > > > > > > > > > U-Boot's private libgcc is not a feature of U-Boot, but a fix for > > > > > > some > > > > > > cases where a target cannot properly link with the libgcc provided > > > > > > by > > > > > > the (specific release of the) GCC toolchain in use. Using private > > > > > > libgcc > > > > > > to other cases than these does not fix or improve anything; those > > > > > > other cases were working and did not require any fix in this > > > > > > respect. > > > > > > > > > > This isn't true, exactly. If using clang for example everyone needs > > > > > to > > > > > enable this code. We're also using -fno-builtin -ffreestanding which > > > > > should limit the amount of interference from the toolchain. And we > > > > > get > > > > > that. > > > > > > > > You mean clang does not produce self-sustained binaries? > > > > > > clang does not provide "libgcc", so there's no -lgcc providing all of > > > the functions that are (today) in: > > > _ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S > > > _umodsi3.S div0.S _uldivmod.S > > > which aside from __modsi3 and __umodsi3 are all __aeabi_xxx > > > > (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 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. Comments welcome. > -- > Tom Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
