Re: l_private (Re: updating COMPAT_LINUX for linux 2.6.x support (take 2))

[Andrew Doran <ad%NetBSD.org@localhost>]

On Wed, Jun 16, 2010 at 10:27:16AM +0200, Joerg Sonnenberger wrote:
> On Wed, Jun 16, 2010 at 06:30:23AM +0000, YAMAMOTO Takashi wrote:
> > i think ucontext is more flexible because this way the kernel doesn't
> > need to know which register etc is used for tls.

The amount of code in kernel to support this is relatively small, and it
gives us an MI way to access the thread local register (_lwp_getprivate).
For sparc64 it's something in the region of 10 lines of code, including
the #define _HAVE_CPU_LWP_SETPRIVATE (just as an example).

> In many cases, the kernel has to know about the private mapping because
> it has to update it on context switches. For x86, it either has to
> modify a GDT entry or a MSR. The actual value of %gs is otherwise
> irrelevant.

It's also emulated elsewhere like on MIPS, so it's not a register that
can be set in ucontext, unless ucontext is modified to hold it.

However, we really do need this stuff in ucontext for threading.  There
are a few use cases but the main one is for signals.  When we create a 
thread we need it to have working TLS/self pointers straight away so
that it can handle signals.  A signal may be delivered to the thread before
it even begins run inside libpthread, so the thread cannot set its own
private pointer.  Alternatives like screwing with signal masks are too
slow or labourious.