On Tue, 2011-05-31 at 16:03 +0100, David Gilbert wrote: > On 31 May 2011 15:35, Richard Earnshaw <rearn...@arm.com> wrote: > > I think the difficulty here is that glibc expects either the compiler, > > or libgcc to provide the sync primitives; and while GCC can tie the > > inlined copy of the primitive to use of CPUs with the relevant > > instruction, the libgcc version doesn't know how to specify that the > > code it's relying on requires a minimal kernel version... > > > > It could throw the dependency back on glibc, but then you've got an > > expensive operation (the libgcc copies are normally implemented as > > private, per-library, helpers to avoid a PLT call overhead). > > You say > 'the libgcc version doesn't know how to specify that the > code it's relying on requires a minimal kernel version...' > > but why isn't that code just in libgcc; if the libgcc helper gets > called and the kernel interface is too old it throws an error.
You don't want to repeat the test every time the sync function is called. That's excessive. Further, you want to know when the program starts if the kernel isn't current enough, not a long way into execution. It might be possible to construct an object file that contained the support, but which also contained a 'constructor' that was run at init time. The 'constructor' would run the kernel version check and terminate the program if it wasn't sufficiently up-to-date. That still begs the question of how this should be done. Not very useful printing a message if the program is based on a GUI. The constructor would have to be run early to avoid the case of another (user or library) constructor needing the sync primitive. > eglibc always uses the compilers sync primitives Which the compiler will either inline, or fall back to the libgcc versions. > > (I've not checked if all of eglibc's atomic's match gcc's or if it > needs any more). > I presume that (e)glibc doesn't use 64-bit sync or we would have added it before now... R. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
