linux-mips
[Top] [All Lists]

Re: anybody tried NPTL?

To: Dominic Sweetman <dom@mips.com>
Subject: Re: anybody tried NPTL?
From: Daniel Jacobowitz <dan@debian.org>
Date: Mon, 23 Aug 2004 09:28:53 -0400
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
In-reply-to: <16678.163.774841.111369@arsenal.mips.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20040804152936.D6269@mvista.com> <16676.46694.564448.344602@arsenal.mips.com> <20040819221646.GC8737@mvista.com> <16678.163.774841.111369@arsenal.mips.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.5.1+cvs20040105i
On Fri, Aug 20, 2004 at 02:46:11PM +0100, Dominic Sweetman wrote:
> I guess our main message was that we felt it would be a mistake just
> to add a thread register to o32 (which produces a substantially
> incompatible new ABI anyway).

Completely agree...

> Until that all works, what we had in mind is that we'd do NPTL over
> o32 by defining a system call to return a per-thread ID which is or
> can be converted into a per-thread data pointer.  We suspected that
> NPTL's per-thread-data model allows the use of cunning macros or
> library functions to make that look OK.
> 
> Ought we to go further and see exactly how that can be done?

It shouldn't be at all hard.  The way NPTL's __thread support works,
the only things that should have to know where the TLS base is are
(A) GCC, so it can load it and (B) GDB, via some new ptrace op.  I
don't know if you'd want to open-code the syscall or take the overhead
of a function call.  Ralf had some ideas?

-- 
Daniel Jacobowitz

<Prev in Thread] Current Thread [Next in Thread>