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 ? Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
