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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
