Thu 19 Jul 2007 08:39:40 PM UTC, comment #15:
Here are updated patches. I don't have any issue any more, other people don't seem to have either.
(file #13404, file #13405, file #13406)
|
Tue 17 Jul 2007 10:24:22 PM UTC, comment #14:
There's one thing I'm not sure how to tackle when fork()+exec()'ing: when fork()'ing, descriptors are correctly set, etc. but when exec()'ing a new program, the descriptors should probably be cleared, because else the new program will inherit them. This should probably be done in hurd/exec/exec.c:do_exec(), at the time when vm areas are cleared. However, while clearing LDT is easy (just set it all to 0), clearing GDT is not: userspace doesn't have access to the USER_GDT and USER_GDT_SLOTS macros. Making 8191 trap calls for clearing them one by one would be quite long. A heuristic would be to try clearing from 0 and then until it starts succeeding, and then continue until it fails again, at which point we can consider every user entries where cleared, but that's far from pretty.
Should we export these two macros, export a new trap call for clearing all at once, something else?
|
Sun 24 Jun 2007 10:34:59 PM UTC, comment #13:
Oops, symbol versioning wasn't working as I expected. Unfortunately, that means that linking a libpthread against a TLS-enabled glibc will produce a TLS-only libpthread.
That said, the -transitional patch will still be useful for Debian's transition.
(file #13156)
|
Sun 24 Jun 2007 02:09:12 PM UTC, comment #12:
Here are updated patches, ext2fs.static now works. mach-defpager doesn't, however.
(file #13147, file #13148, file #13149)
|
Wed 13 Jun 2007 10:02:06 PM UTC, comment #11:
After recompilation of the Hurd servers with the TLS glibc, static binaries don't work any more, that's because we need to call __libc_setup_tls when libc is statically linked, see glibc-2.5/nptl/init.c.
We also have to do exactly the same for libthread.so too, because any piece of code that use create_thread() for starting a thread that uses __thread-enabled glibc should allocate TLS for glibc to work.
|
Wed 13 Jun 2007 05:59:35 AM UTC, comment #10:
Mmm, actually, the unstability I'm getting might be related to my Xen environment. When running natively I don't have any problem and seem for instance to be able to recompile the hurd package without trouble.
|
Wed 13 Jun 2007 05:50:56 AM UTC, comment #9:
I had forgotten that it's up to the thread library to initialize the tcb field of the tcb head.
(file #13034, file #13035)
|
Wed 13 Jun 2007 04:37:11 AM UTC, comment #8:
Here is a different patch for making the transition: the problem is that non-TLS glibc doesn't have _dl_allocate_tls, and thus the TLS libpthread.so can't be used with the old glibc. And non-TLS libpthread.so can't work with a TLS glibc as soon as an application with TLS data starts a thread. Thus the weak symbols for letting TLS-enabled libpthread work with non-TLS glibc.
Debian packages are available on http://dept-info.labri.fr/~thibault/debian-hurd/tls/ : I could install them (hurd first, then libc) and work (apt-get update etc), but now my box is pretty much unstable, it usually doesn't make it through the boot process.
|
Wed 13 Jun 2007 02:43:01 AM UTC, comment #7:
I ran make check in glibc/elf/, only tst-tls9-static failed (it just dlopens() libraries with tls).
Here is the Hurd's libpthread part. A very simple example seems to work just fine.
(file #13032)
|
Tue 12 Jun 2007 12:11:01 AM UTC, comment #6:
Here is a probably better patch for the fork issue. Almost all place should actually save/restore registers, and only new contexts need to let gnumach set initial values of registers.
(file #13021)
|
Mon 06 Nov 2006 03:39:26 PM UTC, comment #5:
Note that since 2006-10-27 tls has been enabled on the glibc trunk unconditionally: <http://sourceware.org/ml/glibc-cvs/2006-q4/msg00177.html>.
|
Mon 06 Nov 2006 03:22:43 PM UTC, comment #4:
Roland's plan was / is to first make `--without-__thread' builds work (i.e. both compile and runtime-wise) before attemping anything else.
|
Mon 06 Nov 2006 03:13:41 PM UTC, comment #3:
The `i386_set_gdt' and `i386_get_gdt' functions (which are --- if available --- used by the glibc tls code instead of the ldt ones) have been back-ported from OSKit Mach to GNU Mach and have been installed on gnumach-1-branch on 2006-11-05: <http://lists.gnu.org/archive/html/commit-hurd/2006-11/msg00007.html>, also see the threads starting at <http://lists.gnu.org/archive/html/bug-hurd/2006-10/msg00095.html>, <http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00017.html> and <http://lists.gnu.org/archive/html/bug-hurd/2006-11/msg00033.html>.
|
Fri 08 Sep 2006 08:34:48 AM UTC, comment #2:
Jeroen Dekkers has been working on this, but stopped his efforts.
| <Jeroen> http://www.dekkers.cx/hurd/glibc-tls.patch
| <Jeroen> the fork fix isn't the right one
| <Jeroen> because the define is i386-specific
| <Jeroen> we should probably define a MACHINE_THREAD_STATE_FLAVOR2 to
| i386_REGS_SEGS_STATE or something, roland will probably know the
| cleanest solution
| <Jeroen> with that patch you can run programs
| <Jeroen> but dlopen() doesn't work
| <Jeroen> maybe other things don't work either
| <Jeroen> but the basic TLS things work :)
|
Fri 08 Sep 2006 08:29:55 AM UTC, comment #1:
Some links:
<http://lists.gnu.org/archive/html/hurd-devel/2006-04/msg00002.html>
<http://lists.gnu.org/archive/html/hurd-devel/2006-09/msg00000.html>
|
Fri 08 Sep 2006 08:27:38 AM UTC, original submission:
We currently have to build glibc with ``--without-tls'' because there are bugs in the Hurd-specific parts of glibc that deal with support for TLS.
However, this doesn't work for glibc 2.4 anymore, as thread local storage is being used internally by glibc and thus building with ``--without-tls'' fails.
|