On 03/24/2016 01:13 AM, Tom Rini wrote: > On Thu, Mar 24, 2016 at 12:49:54AM +0100, 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 ? > > Follow-up _series_ to re-sync our 64bit math stuff with the kernel. > Something tells me this is gonna be one patch , not a series.
-- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
