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

[Graeme Russ]

Hi Mike,

On Fri, Nov 11, 2011 at 4:15 AM, Mike Frysinger <vapier at gentoo.org> wrote:
> On Wednesday 09 November 2011 23:22:34 Graeme Russ wrote:
>> On Thu, Nov 10, 2011 at 3:13 PM, Mike Frysinger wrote:
>> > i was referring also to throwing away -mregparm=3 ...
>>
>> Yes, it does effect the code - It makes it ABI compliant like everyone
>> else (except ARM) :) I expect a code size increase (have not measured
>> it yet)
>
> ABI compliance only matters at the boundaries.  since u-boot is largely self-
> contained, we shouldn't be afraid to break internal ABI.

And I'm not afraid to do so

>> As I've stated, I really do not want arbitrary wrapper functions where
>> it is not obvious that they need to be updated if new code uses
>> previously unused (and unwrapped) libgcc functions (in particular if
>> there are new libgcc functions in the future which we can't wrap
>> todday anyway)
>>
>> Option a) is to remove regparm=3
>> Option b) is to use private libgcc
>> Option c) is to use wrappers
>>
>> If this patch works, I'll look at the code impact and we can discuss
>> which option we take :)
>
> for the record, i'm not against a private libgcc.  it just seems to me that
> the wrapper approach proposed by Gabe has the best pro/con ratio.

I'm sorry, but I must respectfully disagree...

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

Another big(ish) con, for me, is that we already have a mechanism in place
to resolve this (USE_PRIVATE_LIBGCC) - I don't see any benefit to add a
second to the mix

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

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.

Also, We use an existing mechanism and it is in keeping with --no-builtin.
libgcc is really just a library of functions that are too large to
implement as inline functions internally by gcc anyway:

"GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on
 some platforms. GCC generates calls to routines in this library
 automatically, whenever it needs to perform some operation that is too
 complicated to emit inline code for."

Now the downside has been raised regarding keeping the private libgcc
functions in-sync with mainline libgcc - We are only talking about a
handful of functions. There are no floating point or 'special' functions,
so the list is wholly restricted to:

http://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html

I haven't looked at them, but I doubt they are very big (going by the ARM
implementations) and I doubt they change very often (probably not in years)

The more I think about this, the more I feel to just use USE_PRIVATE_LIBGCC

Regards,

Graeme