TLS in Hurd glibc

[Roland McGrath]

I've added a smidgen of code to libc to enable TLS support on Mach/x86.
If you are not already on top of everything with libc, just build using
--without-tls (I guess it's still the default) and get all other
significant problems addressed before worrying about this.

It's written to try both i386_set_gdt and i386_set_ldt.  The former is
new in oskit-mach.  If compiled with an old mach_i386.defs installed, it
won't try to use i386_set_gdt.  If compiled with new headers, it will
try to use it but fall back to i386_set_ldt if it gets MIG_BAD_ID, which
ought to work with gnumach1.

The --with-tls build compiles, but that's the best I can say.  The goal
after the build without TLS is in decent shape is that the make check
tests in elf/tst-tls* will work in a native hurd build.  Ideally we
should test on both gnumach1 and oskit-mach, and verify (by inspection
in the debugger) that it's using the right mechanisms in both.

The tests aren't all that meaningful until there is a way to have
multiple threads that use TLS data, but making them work is the first
step.

cthreads and Neal's libpthread can easily be modified to use
_dl_allocate_tls so that new threads get set up for TLS.  The simple
thing to do first is just tack on the calls and try some tests of TLS
use, but leave the existing thread data structures untouched.

As soon as TLS is nominally working, I want to switch libc to using
those data structures and the thread register for the hurd threadvars.
Then we can punt all the magic for the single-threaded and signal-thread
cases in that stuff, and keep it simple.

Note that TLS support I'm referring to now is just the ELF TLS support,
not the __thread C language extension.  TLS is the layer below __thread.
TLS requires a thread register, i.e. segment register magic on x86.
__thread requires TLS.  We would like to use __thread freely at some
point, but no stable GNU compiler relesae supports it yet.  However,
nothing prevents us from making the TLS support per se work now, and we
benefit from that by cleaning up other code in libc to take advantage of
the thread register.

Getting TLS to work at all should not be a lot of debugging, since we've
already debugged the libc parts heavily on Linux.  Then, it should be a
straightforward and nonperturbing step to use the thread register for
hurd threadvars.  After that works stably, there could be another
nonperturbing step of using it for _hurd_sigstate directly.  Ultimately
that structure should merge with the pthread per-thread structure in the
final libc-integrated pthreads, and it might not be worth bothering with
incremental changes before overhauling signals along with that.