[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TLS support patch
On Thu, 2011-04-07 at 04:50 -0700, Matt Thomas wrote:
> On Apr 6, 2011, at 4:30 PM, Joerg Sonnenberger wrote:
> > Hi all,
> > the attached patch allows TLS support on ARM. I won't commit it, since
> > it will make pthread usage inacceptable slow. I hope someone is going to
> > write the magic for __eabi_read_tp and __lwp_getprivate_fast().
> That's __aeabi_read_tp. I've added kernel emulation so that -mtp=hard
> will work even on those CPUs that don't have that register.
> Assuming we just don't have __aeabi_read_tp just to a
> mrc p15, 0, r0, c13, c0, 3
> and take the emulation hit, what mechanism should be used?
> _lwp_getprivate would be horribly slow. We could reserve a read-only
> kernel page that gets updated by cpu_switchto. Linux does
> mov r0, #0xffff0fff
> sub pc, r0, #31
> which jumps to a known location in the kernel (0xffff0fe0). Since we
> will need to do this for linux emulation anyways, we might as well adopt
> I assume that page contains code (patched at boottime) to either do the
> mrc above or read a fixed location for the current tp.
> ldr r0, .L__aeabi_current_tp
> mov pc, lr
> .word 0
> cpu_switchto would need to update that location. This page will need
> to be per-CPU which is a concept the arm pmap isn't able to cope with
Perhaps the easiest way to have some per-cpu memory is to lock a line
into the dcache. That will need some pmap updates too, so that the line
doesn't get flushed.
Another issue that needs to be addressed is that SWP is deprecated in
the architecture these days and you need to do locking on v7 cores using
LDREX/STREX and friends. Linux also uses kernel stubs to handle this on
legacy cores (code compiled to run only on modern cores can then do
locking using the LDREX etc instructions directly as they know that the
code will not be running on a system that still does locking via SWP).
Main Index |
Thread Index |