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

[Chris Curtis]

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.

--chris

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.