Is this going to end up in a blueprint? This is the last loose end of SMP / atomic memory operations work and I'd like to see it happen
Dave On 18 May 2011, at 16:07, Dave Martin wrote: > 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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
