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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
