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

Gabe Black gabeblack at google.com
Fri Nov 11 03:10:27 CET 2011


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

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.

Gabe


More information about the U-Boot mailing list