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

[Graeme Russ]

On Wed, Nov 9, 2011 at 12:52 PM, Gabe Black <gabeblack at chromium.org> wrote:
>
>
> On Tue, Nov 8, 2011 at 5:25 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>
>> On Wed, Nov 9, 2011 at 12:15 PM, Gabe Black <gabeblack at google.com> wrote:
>> >
>> >
>> > 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
>>
>> Only on 64-bit operations - surely there are other libgcc functions
>> not covered by your patch. And why had I not seen these before - was
>> is a case of never hitting that call path?
>
>
> We didn't see problems for a while either. I guess 64 bit math isn't very
> common in u-boot. I think it also tends to "work" in the sense that nothing
> is wrong enough to fail and no divide by zero exception or other fatal
> problem crops up. There are possibly other libgcc functions which are not
> covered, but this is actually a superset of the functions that are currently
> being used, or at least circa the date this patch was put together. I don't
> think there's all that much to libgcc, but I don't know that for a fact.
>
>>
>> > 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
>>
>> 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?

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

> I don't think it necessarily implements parts of libgcc, I think that's a
> per arch setting. Turning that (USE_PRIVATE_LIBGCC) on didn't work on x86
> when I accidentally did that a while ago.

If you define USE_PRIVATE_LIBGCC then you need to implement the subset of
libgcc required by U-Boot. See arch/arm/lib - Specifically the following
are compiled if USE_PRIVATE_LIBGCC is defined:

	_ashldi3.o
	_ashrdi3.o
	_divsi3.o
	_lshrdi3.o
	_modsi3.o
	_udivsi3.o
	_umodsi3.o
	div0.o


> I would be very surprised if glibc was used by default or otherwise.
> Speaking perhaps too generally, glibc is a big library intended for user
> space applications running under an OS and wouldn't be appropriate to use in
> U-Boot. I have to assume that's why U-Boot implements the libc functionality
> it needs by itself without relying on an external library, even though there
> are libc implementations which are more appropriate for embedded/firmware
> use. In this case, we're grabbing a small bit of code out of glibc and
> transplanting it by itself into u-boot. There's no special linking involved,
> just porting over a single function.

Now we are getting into your 'Wrap small helper functions from libgcc to
avoid an ABI mismatch' patch...