On Tue, May 31, 2011 at 12:53:35PM -0400, Nicolas Pitre wrote: > On Tue, 31 May 2011, Dave Martin wrote: > > > On Tue, May 31, 2011 at 03:35:42PM +0100, Richard Earnshaw 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... > > > > The libgcc 64-bit atomic helpers could do a runtime check on > > the __kernel_helper_version field in the vectors page before calling > > the 64-bit cmpxchg helper. This will allow the absence of the helper > > to be reliably detected on older kernels. Because this is data, it > > might cause an extra D-TLB miss to accompany any other miss associated > > with calling the kernel helper (if it exists). > > Isn't there a way to pull in a global constructor or similar whenever a > reference to the 64-bit cmpxchg helper is made, so that the constructor > code could simply validate the kuser version number and bail out > otherwise?
Hmm, that should be possible. I don't know how this interacts with other constructors: really this would need to run at a defined point early program startup. If it just ends up somewhere in the middle of the list of global constructurs, we'd have a problem if some of the other constructurs try to use the 64-bit atomics. Richard, do you know how this could work? > I know this is certainly the case on x86 that if you statically compile > a binary on a modern distro in the hope of being able to execute that > binary anywhere, you may get a "kernel too old" error message when > trying to run it on older distros. The same thing could be done for the > ARM 64-bit cmpxchg helper as well, at startup rather than on every > invokation, no? As a principle, it feels like it ought to work. Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
