From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 24 Mar 2016 00:24:49 +0100 Subject: [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default In-Reply-To: <20160323230834.GJ23166@bill-the-cat> References: <1458490534-5537-1-git-send-email-marex@denx.de> <1458490534-5537-5-git-send-email-marex@denx.de> <20160323135335.5fbe01ae@lilith> <20160323132238.GA23166@bill-the-cat> <20160323180845.4bbc1035@lilith> <20160323213617.GE23166@bill-the-cat> <20160323230834.GJ23166@bill-the-cat> Message-ID: <56F325C1.9030104@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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