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.
> This code was the source of a TLS
> bug in bionic, and may have been inappropriately pasted elsewhere
> too...)
What bug?
Nicolas
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
