I'd like to clean up the way that it figures out which special vars are thread slots, for sure.

But what else, if anything, is bad about what it's doing? The idea is that any global symbol can be known to have a tls-index. While it certainly works to have the loader figure out the thread slots just the same as any random symbol, that's not quite as good as can be, because the loader will be forced to use a 32-bit displacement to every thread slot.

the debugger regression is due to a wrong storage-class for one temp var.
The number it reports in the unbound variable turns out to be the symbol's address. I'm surprised we didn't have a test for the correct variable in an error handler.

On Thu, Apr 10, 2014 at 8:48 AM, Stas Boukarev <stassats@gmail.com> wrote:
Stas Boukarev <stassats@gmail.com> writes:

> Stas Boukarev <stassats@gmail.com> writes:
>> Eric Marsden <eric.marsden@free.fr> writes:
>>> Hi,
>>> Building current git, I see a SB-GMP build failure on Linux/AMD64. All
>>> 22 of the SB-GMP tests fail with
>>> Actual value: #<SIMPLE-TYPE-ERROR expected-type: SB-GMP::GMP-RSTATE datum: 1>.
>>> I have libgmp-dev with a Debian version of 2:6.0.0+dfsg-2.
>> The breaking commit is 6b74d4aac1a11e776267fbdb3638d9708d74df0f.
>> I'm currently investigating it. But I already noticed a debugger
>> regression:
>> (let ((a abc)) a) =>
>> The variable 68772754895 is unbound.
> It is quite peculiar:
> (let () *state*) in any package returns 1, but warns about an undefined
> variable.
> The name *state* is important for this to fail.
Ok, that's coming from the thread struct:

(let () (list *state* *no-tls-value-marker* *os-thread* *pseudo-atomic-bits*))
(1 #<unknown immediate object, lowtag=#b1, widetag=#x61 {61}> 70368646560640 0)

due to sb-vm::symbol-thread-struct-offset disregarding the package.

But I'm not quite sure about the whole meaning of treating thread slots
in such a way.

With best regards, Stas.