[U-Boot] [RFC] x86: Do no use reparm as it break libgcc linkage

[Mike Frysinger]

On Thursday 10 November 2011 17:53:06 Graeme Russ wrote:
> The biggest con with wrappers is that the proposed patch only wraps four
> functions. arch/arm/lib/ has private libgcc implementations for eight
> libgcc functions - I can only assume they are used somewhere.

i don't think you can look across arches like that.  arm provides a lot more 
libgcc funcs because it, like most RISC/embedded cpus, do not provide 
dedicated math insns in the ISA.  or the number of insns is so large, that 
creating a dedicated library func and emitting a function call makes more 
sense than emitting them inline.  x86 is a fairly "fat" ISA in that most math 
operations can be accomplished in single or a few insns, and is certainly 
better than emitting func calls to an external library.

in fact, building the current eNET board (the only x86 board) shows that it 
doesn't use *any* calls from libgcc:
	make PLATFORM_LIBGCC= eNET -j4

> The kicker
> is that if anyone uses a libgcc function which is not one of the four
> already wrapped, and they do not realise this and fail to wrap them
> themselves, no warning will be given by the compiler or linker. Now that
> unwrapped function may be in a rarely executed code path (as evidenced by
> the fact that this bug has been dormant for a year now). So you could have
> in-the-wild version of U-Boot which start exhibiting strange behaviour and
> nobody knows why

yes, but the better question is whether those funcs should be called in the 
first place

> The final (trivially small) con is the overhead added to these calls

this con is insignificant when weighed against the alternatives: not using 
regparm anywhere.  further, these funcs are rarely used, so you're talking 
about adding a minor amount of overhead to one or two call sites.

> Now if we use USE_PRIVATE_LIBGCC, unimplemented libgcc functions will
> result in link errors, so using an unimplemented libgcc will be obvious at
> build time - It may lead to a posting on the mailing list, but at least we
> won't have latent libgcc related bugs in-the-wild.

perhaps x86 should be setting PLATFORM_LIBGCC to nothing all the time.  the 
funcs Gabe wants to wrap are 64bit operations.  u-boot should not be doing 64-
bit operations.  that's why we have do_div().
-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/20111110/1ed27e65/attachment.pgp