[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: