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.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************