[Openmcl-devel] Solaris x86-64 and %gs
enderx12 at mac.com
Mon Jan 7 15:21:16 EST 2008
On Jan 7, 2008, at 2:24 PM, Gary Byers wrote:
> I installed a recent OpenSolaris build over the weekend, so I might
> be able to answer this sort of thing by peeking at Solaris man pages/
> headers/small code snippets ...
FWIW, I'm running on "official" Solaris U3 (11/06) and U4 (08/07). I
can install OpenSolaris relatively easily, too.
>> From looking at lisp-kernel/thread-manager.c, it looks like
>> setup_tcr_extra_segment doesn't ever get called unless both HAVE_TLS
>> and X8664 are defined (in new_tcr), which may or may not be the case
>> for Solaris. So on the one hand, it looks like it *should* be
>> to run without HAVE_TLS and just get the tcr chain calloc'd. Is this
>> code path actually valid on any current platforms?
> The tcr gets calloc'ed on Darwin.
> There may be some additional Darwin-specific nonsense having to do
> with the fact that the TCR's address is used as a Mach exeption
> port identifier, which means/meant that it has to fit in 32 bits.)
> There's a separate issue related to how we get %gs to point to the
> tcr in each thread; we may have to allocate a segment descriptor
> (if there's a way to do that) and make %gs point to it, or we
> may be able to find something like the Linux/FreeBSD functions
> that do that at a higher level. The message that Matt cited
> made it sound like someone involved in Solaris development
> wanted to provide some simple way of doing this, but as Matt
> noted it wasn't clear if/how this was to be exposed to the
There is a way to allocate segment descriptors: sysi86(SI86DSCR, ...)
but it's not very well documented and so I haven't yet been able to
get it to do anything other than throw EINVAL. Thus, I've been unable
to determine whether a properly-allocated segment descriptor can be
stored into %gs -- mine still segfaults. As I mentioned, this is what
SBCL does under the covers (SI86DSCR, not segfaults) but then puts it
in the %fs register.
>> OTOH, all the asm macros refer to %rcontext (= %gs) so that doesn't
>> seem quite likely.
> In lisp, most code should refer to it as :rcontext, and references to
> :rcontext should look up the actual register in the target backend
> structure. (This was intended to allow us to use %fs for the TCR
> on Darwin, which uses %gs for threads data ... there didn't seem
> to be a way of doing that on x86-64, so we wound up overloading
> %gs instead.) It seems that Solaris follows the standard ABI, so
> we just need to figure out how.
It seems like it ought to be easier than it is turning out to be,
that's for sure. Since it's not really using %gs for the LDT, it seems
intuitively wrong that it's protecting it with the LDT subsystem. More
digging in order there.
> If we did have to make rcontext be something other than %gs (e.g.,
> %fs), then on the kernel side we'd have to define it conditionally
> in a couple of places ...
I don't have a good feel yet for whether that's easier or harder. ;-)
I'm still trying to figure out the register access problem, with not a
lot of clues where to look other than Solaris source code. But I'm
still quixotically optimistic.
> BTW, another Solaris issue (it'd be good to get to the point where
> this is the big issue) has to do with GCC versions: some versions
> of GCC 3.x seem to have problems compiling the kernel source
> the GC) correctly. Disabling -O2 sometimes makes it better; I don't
> know whether the issue has to do with some code in the lisp/gc sources
> depending on non-portable C behavior in some subtle way or whether
> it's an outright bug in GCC 3.x.
I'll look into that (eventually) as well.
More information about the Openmcl-devel