Hi Mike, On Fri, Nov 11, 2011 at 4:15 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Wednesday 09 November 2011 23:22:34 Graeme Russ wrote: >> On Thu, Nov 10, 2011 at 3:13 PM, Mike Frysinger wrote: >> > i was referring also to throwing away -mregparm=3 ... >> >> Yes, it does effect the code - It makes it ABI compliant like everyone >> else (except ARM) :) I expect a code size increase (have not measured >> it yet) > > ABI compliance only matters at the boundaries. since u-boot is largely self- > contained, we shouldn't be afraid to break internal ABI.
And I'm not afraid to do so >> As I've stated, I really do not want arbitrary wrapper functions where >> it is not obvious that they need to be updated if new code uses >> previously unused (and unwrapped) libgcc functions (in particular if >> there are new libgcc functions in the future which we can't wrap >> todday anyway) >> >> Option a) is to remove regparm=3 >> Option b) is to use private libgcc >> Option c) is to use wrappers >> >> If this patch works, I'll look at the code impact and we can discuss >> which option we take :) > > for the record, i'm not against a private libgcc. it just seems to me that > the wrapper approach proposed by Gabe has the best pro/con ratio. I'm sorry, but I must respectfully disagree... 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. 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 Another big(ish) con, for me, is that we already have a mechanism in place to resolve this (USE_PRIVATE_LIBGCC) - I don't see any benefit to add a second to the mix The final (trivially small) con is the overhead added to these calls 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. Also, We use an existing mechanism and it is in keeping with --no-builtin. libgcc is really just a library of functions that are too large to implement as inline functions internally by gcc anyway: "GCC provides a low-level runtime library, libgcc.a or libgcc_s.so.1 on some platforms. GCC generates calls to routines in this library automatically, whenever it needs to perform some operation that is too complicated to emit inline code for." Now the downside has been raised regarding keeping the private libgcc functions in-sync with mainline libgcc - We are only talking about a handful of functions. There are no floating point or 'special' functions, so the list is wholly restricted to: http://gcc.gnu.org/onlinedocs/gccint/Integer-library-routines.html I haven't looked at them, but I doubt they are very big (going by the ARM implementations) and I doubt they change very often (probably not in years) The more I think about this, the more I feel to just use USE_PRIVATE_LIBGCC Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
