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

[Graeme Russ]

Hi Gabe,

On Fri, Nov 11, 2011 at 1:41 PM, Gabe Black <gabeblack at google.com> wrote:
>
>
> 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:

[snip]

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

Ah, so your libraries are regparm(3)

Still, life is going to get interesting for anyone linking in libraries
that are not the saem ABI as U-Boot (as we have seen with libgcc)

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

Remember, U-Boot uses --no-builtin, so apart from the libgcc functions,
there are no gcc functions included. And we are not 'reimplementing
libgcc', we are either 'reimplementing a select few functions' or 'not
using any libgcc functions in U-Boot at all'. So a build will only break
when code is added that uses a function never before used - There should
not be any build breakage due to 'functions added silently by newer
versions of gcc'

I'm assuming that it is the 'verified boot infrastructure' libraries that
are introducing the calls to libgcc? If that is the case, then it is
starting to get very messy - Why should U-Boot have to deal with this?

Regards,

Graeme