[Openmcl-devel] Solaris x86-64 and %gs
enderx12 at mac.com
Sun Jan 13 22:05:18 EST 2008
Well, it was encouraging for a while....
It actually looks like the right function from <sys/lwp.h> would be
_lwp_private(_LWP_SETPRIVATE, _LWP_GSBASE, ...); the only problem is
that that function is only local in libc. (Then why bother definining
it publicly in a header, one might ask, but oh well.)
So I don't know if there's a magic linker incantation to make it
visible, though it seems like one such would be a Bad Idea in
principle. I'm not quite fully defeated yet, but it might be time to
start thinking about how we'd work around not being able to set %gs or
On Jan 12, 2008, at 9:32 AM, Chris Curtis wrote:
> 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
>> 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.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel