On Thu, 24 Mar 2016, Marek Vasut wrote:
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 > > > > > > > > trini@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 > > > > > > > > > > marex@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.
OK, it worked. Now it is time to push it into the official tree :)
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************