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.
