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.
