[U-Boot] [PATCH v2] x86: Import the glibc memset implementation

[Graeme Russ]

Hi Wolfgang,

On Wed, Nov 9, 2011 at 4:36 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <CALButCJq9GdNb5ZtaUb7nepQMV7ULPcR01fon2SxcLdRoPzg+g at mail.gmail.com> you wrote:
>>
>> My point is, why does U-Boot implement parts of libgcc so as to not
>> link to libgcc, but uses (by default) glibc - Why not always implement
>> both, or always (by default) link to both?
>
> We do NOT link glibc.  IF there should beany such case anywhere, it
> would be a bug that needs urgent fixing.

I've already corrected my mis-statement on this - We link to libgcc

My issue is that this link can be tenuous and very subtle (the x86
case has been wrong forever but slipped through because the failure
scenario has only just been picked up)

I understand the argument for linking to libgcc, but I have several against:
 - U-Boot x68 uses regparm which changes the ABI and is, therefore,
inconsistent with libgcc which result in either coding out regparm or
implementing wrappers
 - Implementing wrappers for in-use functions adds overhead (I'm not
really worried by this at all in reality)
 - Implementing wrappers may cover all the 'right now' cases, but the
solution is non-obvious to anyone that, for whatever reason, uses a
libgcc function which is not wrapped. There is no linker error, and
the failure may be non-obvious
 - On an x64 build machine, default 64-bit installs of gcc/binutils
will provide a compiler and linker with command line options to
compile 32-bit code (-m32) but this is not sufficient - You also need
to install 32-bit libgcc (and x86 needs patches to handle specifying
the location of said 32-bit libgcc)

Of all the issues, it is the third that worries me the most. If U-Boot
uses an ABI not compatible with a library, then, IMHO, we should not
link to that library (wrappers or not) - We are just asking for
trouble...

We already have one 'hack' to get around ABI issues - I'm not a fan of
adding another.

Regards,

Graeme