[U-Boot] [PATCH v2] x86: Wrap small helper functions from libgcc to avoid an ABI mismatch

[Mike Frysinger]

On Tuesday 08 November 2011 22:57:31 Graeme Russ wrote:
> On Wed, Nov 9, 2011 at 3:49 PM, Mike Frysinger wrote:
> > On Tuesday 08 November 2011 18:14:46 Graeme Russ wrote:
> >> Ah, yes you have - Can you give me a list? I think to be pragmatic we
> >> should either wrap the all or go down the private libgcc path like ARM
> >> has done. Private lib functions would elliminate the overhead, but is
> >> this really such a problem anyway?
> > 
> > it then becomes a sync issue ... updates to gcc's libgcc aren't reflected
> > in u- boot automatically ...
> 
> Are those updates needed?

you mean bug/math fixes and optimizations ?  i would think so.

> We already have a fair chunk of libc which is not automatically sync'd

we have very very little of glibc ... really only a few optimized 
string/memory funcs, and those aren't glibc specific.  the only other C lib 
type stuff is taken from Linux, or zlib, or dlmalloc, or other locations that 
aren't possible to link against.  libgcc is a bit unique in this regard.

> and going by what is in arch/arm/lib,
> there are very few libgcc functions (far less than libc) and each of
> those are relatively trivial and unlikely to require updating.

it depends on the architecture.  if the core ISA doesn't change, then the math 
funcs won't change much.  i'm not terribly familiar with the gcc x86 internals 
to say how much we actually rely on libgcc.a considering most of the fun stuff 
is real hardware insns.  unlike the normal embedded risc arches which need to 
implement more complicated funcs with many insns.

> Also, I already know of issues compiling U-Boot on an x64 OS because
> of the 32/64 bit incompatibility of libgcc. I never encountered this
> because I only have a 32-bit build machine

yes, this would be an issue, although most people on x86-64 have multilib 
toolchains, so it'd work anyways.  maybe the x86 config.mk should be 
automatically adding -m32 when available.

> So the handful of libgcc functions are starting to become a
> disproportionate headache

seems fairly low to me, but i'm not the x86 maintainer.  i'm not seeing these 
funcs in Linux' arch/x86/ tree though ... maybe there's a better solution ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111109/21da441d/attachment.pgp