Hi Mike, On Fri, Nov 11, 2011 at 11:23 AM, Mike Frysinger <vap...@gentoo.org> wrote: > 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
Which supports my point - The issue was latent because there were no call sites > >> 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 But we can't control that - especially if the code is not submitted to mainline. Then get people hitting the ML asking for help with non mainline code because they used a function they did not know they should not have used and they are seeing some random weird crash >> 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. 100% agree >> 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(). Remember that there was a lot of discussion regarding the timer API that pointed towards using 64-bit counters for all arches. We cannot take it as gospel that 64-bit operations will never be used in U-Boot. Some people may have a need for this as part of hardware init. Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
