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.pitre@linaro.org wrote:
On Tue, 17 May 2011, Dave Martin wrote:
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 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