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

[Gabe Black]

On Tue, Nov 8, 2011 at 5:10 PM, Graeme Russ <graeme.russ at gmail.com> wrote:

> Hi Gabe,
>
> first up - Please stop top-posting
>
> On Wed, Nov 9, 2011 at 11:59 AM, Gabe Black <gabeblack at chromium.org>
> wrote:
> > I'm pretty sure u-boot doesn't link with glibc. I'd expect that to cause
> all
> > sorts of problems on top of being really big. There are default, generic
> > implementations which it can use, or you can specialize them to take
> > advantage of architecture specific features like I'm doing here.
>
> Hmm,
>
> # Add GCC lib
> ifdef USE_PRIVATE_LIBGCC
> ifeq ("$(USE_PRIVATE_LIBGCC)", "yes")
> PLATFORM_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/libgcc.o
> else
> PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
> endif
> else
> PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
> -print-libgcc-file-name`) -lgcc
> endif
> PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> export PLATFORM_LIBS
>
> So we link with libgcc - In another email I raise the question of why
> regparm is not conflicting here
>
> And why do we have an option to not link to libgcc, but on the other
> hand we never link to libc - I'm confused
>
> Regards,
>
> Graeme
>
>
I don't understand the question. regparm did conflict, which is the point
of my other patch. Why would having an option to link libgcc have anything
to do with glibc? U-Boot has its own partial libc implementation which has
generic implementations of certain functions which can be overridden. By
not linking to the generic implementation and providing a specialized one,
the performance improves two fold. Those are the two choices.

Gabe