On Tue, Nov 8, 2011 at 5:25 PM, Graeme Russ <graeme.r...@gmail.com> wrote:
> On Wed, Nov 9, 2011 at 12:15 PM, Gabe Black <gabebl...@google.com> wrote:
> >
> >
> > On Tue, Nov 8, 2011 at 5:10 PM, Graeme Russ <graeme.r...@gmail.com>
> wrote:
> >>
> >> Hi Gabe,
> >>
> >> first up - Please stop top-posting
> >>
> >> On Wed, Nov 9, 2011 at 11:59 AM, Gabe Black <gabebl...@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?
>
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.
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.
>
> > linking to the generic implementation and providing a specialized one,
> the
> > performance improves two fold. Those are the two choices.
>
> Regards,
>
> Graeme
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
