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 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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot