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

[Graeme Russ]

Hi Mike,

On Fri, Nov 11, 2011 at 11:23 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> 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

Which supports my point - The issue was latent because there were no call
sites

>
>> 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

But we can't control that - especially if the code is not submitted to
mainline. Then get people hitting the ML asking for help with non mainline
code because they used a function they did not know they should not have
used and they are seeing some random weird crash

>> 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.

100% agree

>> 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().

Remember that there was a lot of discussion regarding the timer API that
pointed towards using 64-bit counters for all arches. We cannot take it
as gospel that 64-bit operations will never be used in U-Boot. Some people
may have a need for this as part of hardware init.

Regards,

Graeme