[Openmcl-devel] Solaris x86-64 and %gs

Chris Curtis enderx12 at mac.com
Sat Jan 12 06:32:45 PST 2008

Aha! Sounds like the right track; I've been looking along the GSBASE  
line, and you beat me to it. ;-)

 From my reading of the CCL source code, it looks like it's only  
technically true that the thread manager uses %gs to dereference the  
TCR... on both FreeBSD and Linux the system calls set the GSBASE MSR  
(amd64_set_gsbase on FreeBSD), which is the hardware base offset for  
%gs, which itself is then always zero.

(This seems to be true even though the linux call is  
arch_prctl(ARCH_SET_GS,...) ... the manpage talks about setting the  
base; the source code itself is fairly rococo.)

As far as the LWP/pthread correspondence goes... LWPs are the kernel  
threads, and while originally they were a different pool that user  
pthreads (and the non-POSIX "Solaris Threads") were scheduled onto,  
since Solaris 9 they've been 1:1 with user threads, so there shouldn't  
be anything we need to worry about there.


On Jan 12, 2008, at 2:49 AM, Gary Byers wrote:

> I poked around a little in the OpenSolaris sources.
> I think that the incantation we want to use in the #ifdef SOLARIS
> case of setup_tcr_extra_segment() is something like:
> #include <sys/lwp.h>
> #include <sys/proc.h>
> _lwp_setprivate(lwp, _LWP_GSBASE, tcr);
> where lwp is a "lightweight process" and there's some correspondence
> between an lwp and a pthread which would probably be clear to
> anyone who's read Solaris thread documentation recently.
> (Or at least more recently than I have ...)
> My best guess is that we want to try to arrange that the
> correspondence between pthreads and Solaris LWPs is 1:1.  I don't know
> if that's the default, but I assume that there's some way to arrange
> that 1:1 correspondence and that other things (reasonable behavior of
> alternate signal stacks ?)  may depend on that 1:1 mapping.

More information about the Openmcl-devel mailing list