[Openmcl-devel] Solaris x86-64 and %gs
enderx12 at mac.com
Sat Jan 12 14:32:45 UTC 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