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