From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 10 Nov 2011 19:23:41 -0500 Subject: [U-Boot] [RFC] x86: Do no use reparm as it break libgcc linkage In-Reply-To: References: <1320834779-15460-1-git-send-email-graeme.russ@gmail.com> <201111101215.33554.vapier@gentoo.org> Message-ID: <201111101923.43701.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thursday 10 November 2011 17:53:06 Graeme Russ wrote: > The biggest con with wrappers is that the proposed patch only wraps four > functions. arch/arm/lib/ has private libgcc implementations for eight > libgcc functions - I can only assume they are used somewhere. i don't think you can look across arches like that. arm provides a lot more libgcc funcs because it, like most RISC/embedded cpus, do not provide dedicated math insns in the ISA. or the number of insns is so large, that creating a dedicated library func and emitting a function call makes more sense than emitting them inline. x86 is a fairly "fat" ISA in that most math operations can be accomplished in single or a few insns, and is certainly better than emitting func calls to an external library. in fact, building the current eNET board (the only x86 board) shows that it doesn't use *any* calls from libgcc: make PLATFORM_LIBGCC= eNET -j4 > The kicker > is that if anyone uses a libgcc function which is not one of the four > already wrapped, and they do not realise this and fail to wrap them > themselves, no warning will be given by the compiler or linker. Now that > unwrapped function may be in a rarely executed code path (as evidenced by > the fact that this bug has been dormant for a year now). So you could have > in-the-wild version of U-Boot which start exhibiting strange behaviour and > nobody knows why yes, but the better question is whether those funcs should be called in the first place > The final (trivially small) con is the overhead added to these calls this con is insignificant when weighed against the alternatives: not using regparm anywhere. further, these funcs are rarely used, so you're talking about adding a minor amount of overhead to one or two call sites. > Now if we use USE_PRIVATE_LIBGCC, unimplemented libgcc functions will > result in link errors, so using an unimplemented libgcc will be obvious at > build time - It may lead to a posting on the mailing list, but at least we > won't have latent libgcc related bugs in-the-wild. perhaps x86 should be setting PLATFORM_LIBGCC to nothing all the time. the funcs Gabe wants to wrap are 64bit operations. u-boot should not be doing 64- bit operations. that's why we have do_div(). -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20111110/1ed27e65/attachment.pgp