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

[Graeme Russ]

Hi Gabe,

On Fri, Nov 11, 2011 at 1:10 PM, Gabe Black <gabeblack at google.com> wrote:
> On Thu, Nov 10, 2011 at 5:59 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>
>> Hi Mike,
>>
>> On Fri, Nov 11, 2011 at 12:55 PM, Mike Frysinger <vapier at gentoo.org>
>> wrote:
>> > On Thursday 10 November 2011 20:51:47 Graeme Russ wrote:
>> >> A few questions (I am unfamiliar with the Linux build environment):
>> >>
>> >>  a) Does Linux link to libgcc
>> >
>> > no Linux port uses libgcc.  they've always done the equivalent of
>> > PRIVATE_LIBGCC.  but in the case of x86, i can't see them providing any
>> > libgcc
>> > funcs.  so i don't think u-boot should either.
>> >
>> >>  b) Does Linux use regparm
>> >
>> > yes, it uses -mregparm=3
>>
>> Well I think we have an answer - use PRIVATE_LIBGCC but do not implement
>> any libgcc functions and treat link errors as coding errors. If for some
>> bizarre reason we need to really, truly, honestly use a 64-bit libgcc
>> function, we'll port it over then
>>
>> Regards,
>>
>> Graeme
>
> I haven't checked in on this thread in a little while, but I wanted to point
> out some things. First, I was originally planning to measure the performance
> difference with regparm turned off. I realized that would be quite annoying
> to actually do, though, since we have a number of extra libraries linked
> into u-boot and they would all have to be recompiled with different options.

I assume they are all GPL :)

> Then the things they link with would have to be recompiled, etc. Even if
> upstream U-Boot drops regparm, we may need to keep it just for that reason.

Hmm, that raises an interresing point - by using a non-standard ABI we can
run afoul of external libraries. Which raises the question - what external
libraries do you need to link to?

> Second, I think I have a solution that preserves regparm, keeps libgcc and
> gcc in sync, and also stops unwrapped functions slipping into u-boot. We can
> use this command:
> objcopy /path/to/your/libgcc/libgcc.a
> /somewhere/in/the/u-boot/build/libgcc.a --prefix-symbols=__real
> to create a libgcc that has all of its symbols prefixed with the string
> __real. Then *all* symbols are prepped for wrapping, regardless of if we use
> them now or even know about them. Only the symbols we've explicitly wrapped
> will be available. Note that I haven't actually implemented this yet, but it
> seems to me like it captures the positive aspects of all the alternatives.

Sorry, I find that rather un-aesthetic - We are only looking at a trivial
handful of functions, and to copy and rename ALL the symbols in libgcc.a
is rather overkill

The other thing I like about using PRIVATE_LIBGCC is that on 64-bit build
platforms, we don't need to worry about installing 32-bit libraries - All
we need to do is add the -m32 option to tell gcc and ld to generate 32-bit
code

Regards,

Graeme