On Fri, May 6, 2011 at 10:39 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 May 2011, Ramana Radhakrishnan wrote:
On 6 May 2011 16:06, Ken Werner ken.werner@linaro.org wrote:
Currently the GCC ARM backend doesn't provide a pattern to inline 64bit __sync_* functions but the compiler emits __sync_*_8 function calls [1]. The libgcc does not provide these symbols via the usual thin wrapper around the kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only. My understanding is that for ARMv7 the GCC backend could be enhanced to inline the __sync_* functions by using the LDREXD and STREXD instructions. But for ARMv5 we would still rely on a new kernel helper.
It's a bit tricky with when you want to use the kernel helper for v5t, so we've got to find a way of turning this on only with special knobs and not by default and that's a bit tricky.
What is the problem with v5t?
Think new user space and old kernel and a jump into never-never land.
The kernel helpers are "versioned". At 0xffff0ffc you can read the number of helpers currently available. If a program uses a new helper then when it is started this value can be verified to equal or exceed the expected value and bail out otherwise.
To what extent do we think that userspace code is actually checking this?
I may suggest a patch to the documentation text in entry-armv.S to make this requirement clearer, as well as getting rid of the example assembler code (which I consider to be mis-educative, but more importantly it's also Thumb-incompatible and will likely suffer poor branch-prediction on recent CPUs. This code was the source of a TLS bug in bionic, and may have been inappropriately pasted elsewhere too...)
Cheers ---Dave