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 > > > > > > > > <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 >>>>>>>>>>>>>>>>> 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 complaining about assembly syntax in div64.S: >>> >>> === Cut === >>> arch/arm/lib/div64.S: Assembler messages: >>> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl >>> ip)' >>> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)' >>> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)' >>> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' >>> failed >>> make[1]: *** [arch/arm/lib/div64.o] Error 1 >>> Makefile:1214: recipe for target 'arch/arm/lib' failed >>> make: *** [arch/arm/lib] Error 2 >>> === Cut === >>> >>> Probably something is missing in div64.h? The Linux one is totally >>> different. Digging in right now... >> >> Are you building the stuff with all of these 5+1 patches ? > > Nope. Aren't those already in U-Boot master? I pulled the latest master and > thought those were there. If not would you please send me those 5 > patches so > I wouldn't have to hunt them through archives?
I'll send you all six off-list. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
