On Fri, May 6, 2011 at 10:39 PM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Fri, 6 May 2011, Ramana Radhakrishnan wrote: > >> On 6 May 2011 16:06, Ken Werner <ken.wer...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
