On Tue, May 17, 2011 at 5:30 PM, Nicolas Pitre <nicolas.pi...@linaro.org> wrote: > On Tue, 17 May 2011, Dave Martin wrote: > >> 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 think right now it is none of it simply because most of the helpers > were added almost all at once. But if future helpers are added then it > would be a good idea to check this but only if the new helper is > actually invoked for a given application. > >> 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. > > If you have suggestions for improving this then please do so.
I have a patch which I'll suggest at some point, but it's not high priority. > >> This code was the source of a TLS >> bug in bionic, and may have been inappropriately pasted elsewhere >> too...) > > What bug? Actually, to be fair I think I may be mis-remembering here... I can't seem to find the exact bug now. Cheers ---Dave _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
