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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
