On Thu, Nov 10, 2011 at 5:59 PM, Graeme Russ <graeme.r...@gmail.com> wrote:
> Hi Mike, > > On Fri, Nov 11, 2011 at 12:55 PM, Mike Frysinger <vap...@gentoo.org> > wrote: > > On Thursday 10 November 2011 20:51:47 Graeme Russ wrote: > >> A few questions (I am unfamiliar with the Linux build environment): > >> > >> a) Does Linux link to libgcc > > > > no Linux port uses libgcc. they've always done the equivalent of > > PRIVATE_LIBGCC. but in the case of x86, i can't see them providing any > libgcc > > funcs. so i don't think u-boot should either. > > > >> b) Does Linux use regparm > > > > yes, it uses -mregparm=3 > > Well I think we have an answer - use PRIVATE_LIBGCC but do not implement > any libgcc functions and treat link errors as coding errors. If for some > bizarre reason we need to really, truly, honestly use a 64-bit libgcc > function, we'll port it over then > > Regards, > > Graeme > I haven't checked in on this thread in a little while, but I wanted to point out some things. First, I was originally planning to measure the performance difference with regparm turned off. I realized that would be quite annoying to actually do, though, since we have a number of extra libraries linked into u-boot and they would all have to be recompiled with different options. Then the things they link with would have to be recompiled, etc. Even if upstream U-Boot drops regparm, we may need to keep it just for that reason. Second, I think I have a solution that preserves regparm, keeps libgcc and gcc in sync, and also stops unwrapped functions slipping into u-boot. We can use this command: objcopy /path/to/your/libgcc/libgcc.a /somewhere/in/the/u-boot/build/libgcc.a --prefix-symbols=__real to create a libgcc that has all of its symbols prefixed with the string __real. Then *all* symbols are prepped for wrapping, regardless of if we use them now or even know about them. Only the symbols we've explicitly wrapped will be available. Note that I haven't actually implemented this yet, but it seems to me like it captures the positive aspects of all the alternatives. Gabe
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
