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

[Scott Wood]

On 11/08/2011 10:55 PM, Mike Frysinger wrote:
> On Tuesday 08 November 2011 21:53:04 Graeme Russ wrote:
>> Oops, I meant U-Boot implements a subset of (g)libc. I think I understand
>> why - U-Boot needs specific implementations of stdio (printf() and friends)
>> Because we need to implement _some_ of glibc, we need to implement all (or
>> at least all the functions we use) otherwise we will get all sorts of
>> symbol conflicts in the linker
> 
> glibc assumes an OS.  there's no way around that.  u-boot doesn't have an OS, 
> so it has never linked against glibc (ignoring the "sandbox" arch).  libgcc is 
> a different issue: it rarely (if ever) relies on an OS.  it's largely pure math 
> functions, so u-boot has historically used it since things "just worked".

Plus, libgcc is closely bound to compiler internals.

> the reason for arm getting the private libgcc is because (1) newer versions of 
> libgcc started to rely on the OS (see the whole libgcc-likes-to-call-abort()) 
> and

IMHO it's reasonable for the compiler to want a way to report fatal
errors from its runtime -- define it in the linker script as NULL, or
point it at some existing exception/error code, if you don't want to
spend the few bytes on a stub implementation (though we typically spend
a bunch more bytes on exception vectors to handle similar errors...).

The environmental requirements of the compiler (which could come from
either libgcc or directly generated code) are documented in section 2.1
of the GCC manual:

>  Most of the compiler support routines used by GCC are present in
> `libgcc', but there are a few exceptions.  GCC requires the
> freestanding environment provide `memcpy', `memmove', `memset' and
> `memcmp'.  Finally, if `__builtin_trap' is used, and the target does
> not implement the `trap' pattern, then GCC will emit a call to `abort'.

The "if __builtin_trap is used" clause should be removed if libgcc uses
__builtin_trap() (or otherwise calls abort()), though.

> (2) the ABI hell that ARM is currently in -- the hard/soft/vfp/etc..., and 
> little vs big endian.  it ends up being pretty hard to get a single sane arm 
> toolchain to build all the u-boot arm targets.

Last I tried, I couldn't get it to work even with USE_PRIVATE_LIBGCC,
because the compiler was generating calls to things that U-Boot didn't
implement.

-Scott