Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2
On Fri, Nov 30, 2007 at 07:05:05PM +0000, Joseph S. Myers wrote:
> CodeSourcery has been investigating implementing TLS (Thread-Local
> Storage) and NPTL (Native POSIX Thread Library) for ColdFire
> processors. The proposed TLS ABI for ColdFire and m68k, including the
> required kernel interfaces, is below; any comments?
It's good to see someone with more incentive working on this. I had
started looking at it, but it was never exactly a high priority. If
it makes sense for you, I'd like to help out with this. However, I know
many of the steps required have to be pretty serialized. This would
make coordination with someone outside your internal scheduling
somewhat more complicated, I imagine. Let me know if there's something
that would really help you out, otherwise I'll just continue poking
at it on my own once in a while.
> * There are no spare registers available to designate as the thread
> register. Therefore, kernel magic is needed to obtain the thread
> pointer from userspace. Kernel helpers are provided in a vDSO since
> they will need unwind information associated; see details below.
> Compiler-generated code will use an ABI-defined function
> __m68k_read_tp with that function handling the details of calling
> the vDSO.
Have you thought about where this pointer will be stored? A vDSO is
normally shared across all processes and has no thread specific data.
With it being abstracted out this way, it wouldn't need to be documented,
but I'm curious if you have any better ideas than just making it a
system call to read and write this value and store it in the thread
context structure.
> The helper __kernel_atomic_cmpxchg_32 compares the 32-bit value at the
> location pointed to by a0 with the value in d0. If the values are
> equal, it writes the value in d1 to the location pointed to by a0;
> otherwise, it writes the value at the location pointed to by a0 to d0.
> It does not clobber any registers other than the condition codes (and
> the modification of d0 indicated so that d0 is returned with the
> original value of the memory location in all cases). (On m68k - where
> this kernel helper would only be used if glibc is built for the
> intersection of ColdFire and m68k - this could be implemented with a
> single cas instruction and a return.)
I presume ColdFire is also missing CAS2. Do we need a 64 bit cmpxchg
equivalent as well?
> The helper __kernel_atomic_barrier provides a memory barrier. It does
> not clobber any registers other than the condition codes. On non-SMP,
> it can just return to the user; on SMP it needs to ensure memory
> synchronization between processors.
Can you get SMP ColdFire boxes? Linux has historically not supported
SMP on m68k, and much of the code isn't really SMP safe (particularly
some of the drivers for 68k based systems). This isn't to say we
shouldn't have this option, but it seems like a low priority.
Brad Boyer
flar@allandria.com
Reply to: