Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2
On Fri, 30 Nov 2007, Brad Boyer wrote:
> > * 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.
With the ARM magic kernel page the pointer is stored at another location
in that page - we decided against using a magic page with a fixed address
as part of the interface on m68k/ColdFire, in favour of using a vDSO,
because of unwinding and debugging problems associated with executing code
in a magic page (whereas a vDSO acts more or less like another shared
library from that point of view), but the kernel could choose to map
another page per thread (at a fixed address but not one used directly
except by the vDSO and not one used for any executable code) and keep the
thread pointer in there. Or it could use a system call, though that would
be slower.
> > 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?
No, 32-bit compare-and-exchange suffices for NPTL; it's the only one for
which ARM has a kernel helper, and the others are set to cause NPTL to
fail to link if they get used. (If a future version of NPTL starts to
need more atomic operations, then we may need to add more kernel helpers
at that point.)
> > 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.
I don't know if SMP exists at present, but the aim is that glibc binaries
built now should work on any future SMP hardware and kernels, which seems
to require a kernel barrier operation unless you know there will never be
SMP hardware (or that such hardware will have a memory architecture not
needing the barriers).
--
Joseph S. Myers
joseph@codesourcery.com
Reply to: