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

[Chris Curtis]

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  
>> possible
>> 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
> user.

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  
> (especially
> 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.

--chris