Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2

[Brad Boyer <flar@allandria.com>]

On Sat, Dec 01, 2007 at 01:08:07AM +0000, Joseph S. Myers wrote:
> 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.

I suppose we could add a page at a fixed virtual offset from the vDSO
base address. That would make the code sequence easier since we would
presumably could use PC-relative addressing in the vDSO code. This would
be much better than having a fixed virtual address. I'm just worried
about the overhead of having an extra page per thread to store 32 bits.
Any ideas on other things that could be put here to make it more worth
the cost? Perhaps there are some system calls we could turn into a
normal memory load out of this special page pre-loaded with data. The
powerpc port does a few system calls that way out of the vDSO, but it's
not anything thread specific since their data page is shared.

I also tried to look for the ARM magic page implementation, but I
couldn't find it. Any pointers to where I should be looking? I've
never done any work on ARM other than looking at some of the chip
documentation and some decidedly non-Linux implementations.

	Brad Boyer
	flar@allandria.com