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

[Gabe Black]

On Thu, Nov 10, 2011 at 6:22 PM, Graeme Russ <graeme.russ at gmail.com> wrote:

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


You have it reversed. By using a standard ABI we run afoul of external
libraries. We implement our verified boot infrastructure as a library most
notably, and it links in a few other libraries.



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



This argument really doesn't make any sense to me. The number of symbols
involved doesn't make any difference at all. You could imagine we are only
copying a few if you want and there would be no visible, hence aesthetic,
difference. Reimplementing libgcc, along with the inevitable bugs that go
along with new code, breaking builds when new functions are added silently
by new versions of gcc, etc., seems much less appealing in basically every
respect.

Gabe