URL:
<>
Summary: glibc: support for TLS
Project: The GNU Hurd
Submitted by: tschwinge
Submitted on: Friday 09/08/06 at 10:27
Category: glibc
Severity: 5 - Blocker
Priority: 7 - High
Item Group: Standard Compliance
Status: None
Privacy: Public
Assigned to: None
Name:
Email:
/Closed:
Reproducibility: Every Time
Size (loc): None
Planned Release: None
Effort: 0.00
Details:
We currently have to build glibc with ``'' 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 ``''
fails.
Reply to this item at:
<>
Message sent via/by Savannah
http://savannah.gnu.org/
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #2, bug #17644 (project hurd):

Jeroen Dekkers has been working on this, but stopped his efforts.
* GNU Mach:
<>
* glibc
| <Jeroen
| <Jeroenthe fork fix isn't the right one
| <Jeroenbecause the define is i386-specific
| <Jeroenwe should probably define a MACHINE_THREAD_STATE_FLAVR2 to
| i386_REGS_SEGS_STATE or something, roland will probably know the
| cleanest solution
| <Jeroenwith that patch you can run programs
| <Jeroenbut dlopen() doesn't work
| <Jeroenmaybe other things don't work either
| <Jeroenbut the basic TLS things work :)

Additional Item Attachment:

File name: glibc-tls.patch Size:1 KB
Uncompleted patch for glibc.
<>

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #3, bug #17644 (project hurd):

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 SKit Mach to GNU Mach and have been installed on gnumach-1-branch on
2006-11-05:
<>, also
see the threads starting at
<>,
<and
<>.

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #4, bug #17644 (project hurd):

Roland's plan was / is to first make `' builds work (i.e.
both compile and runtime-wise) before attemping anything else.

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #5, bug #17644 (project hurd):

Note that since 2006-10-27 tls has been enabled on the glibc trunk
unconditionally: <>.

Reply to this item at:

<>

Message sent via/by Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #6, bug #17644 (project hurd):

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)

Additional Item Attachment:

File name: patch-glibc Size:3 KB

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #7, bug #17644 (project hurd):

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)

Additional Item Attachment:

File name: patch-hurd Size:7 KB

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #8, bug #17644 (project hurd):

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.

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Additional Item Attachment, bug #17644 (project hurd):
File name: patch-hurd-tls-transitional Size:7 KB
Reply to this item at:
<>
Message via/par Savannah
http://savannah.gnu.org/
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #9, bug #17644 (project hurd):

I had forgotten that it's up to the thread library to initialize the tcb
field of the tcb head.

(file #13034, file #13035)

Additional Item Attachment:

File name: patch-hurd-tls-transitional Size:7 KB
File name: patch-hurd Size:7 KB

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #10, bug #17644 (project hurd):

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.

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #11, bug #17644 (project hurd):

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.

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Samuel Thibault, le Wed 13 Jun 2007 22:02:07 +0000, a :
After recompilation of the Hurd servers with the TLS glibc, static binaries
don't work any more,
static servers, I meant.
Samuel
Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #12, bug #17644 (project hurd):

Here are updated patches, ext2fs.static now works. mach-defpager doesn't,
however.

(file #13147, file #13148, file #13149)

Additional Item Attachment:

File name: patch-glibc-2.5-tls Size:4 KB
File name: patch-hurd-tls-transitional Size:14 KB
File name: patch-hurd-tls Size:12 KB

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hi,

I updated my TLS patches on savannah. Neal, can you have a look at
the hurd part? It is relatively straight forward, it shouldn't be a
problem. As I said earlier, the -transitional version is only meant for
a debian transition package.

Now, here is the glibc part inline for discussion:

First I had to make MACHINE_THREAD_STATE_FLAVR defined to
i386_REGS_SEGS_STATE instead of i386_THREAD_STATE_****, because in many
places, we need to save/restore the segment registers as well. However,
this breaks some places that create new contexts and don't want to
know about segments, so I added MACHINE_NEW_THREAD_STATE_FLAVR which
is defined to i386_THREAD_STATE_****, and used that instead in those
places.

The second part is composed of two initialization fixups:
- when using cthreads, init() copies argc, argv and envp to a new stack,
add a hurd_startup_data structure, and switches to it. However,
argv[0], are not copied, so that the test ((void *) d == argv[0])
always evaluates to false. A simple way to fix it is after finding out
that ((void *) d != argv[0]) (which means we have a hurd_startup_data
structure in d), to check that phdr was provided by the exec server
or was zeroed by init().
- _start points on the first instruction, not on the elf header.
__executable_start does point on the elf header.

Samuel

Index: hurd/hurdfault.c

RCS file: /,v
retrieving revision 1.21
diff -u -p -r1.21 hurdfault.c
hurd/hurdfault.c21 Dec 2005 22:16:20 -00001.21
hurd/hurdfault.c12 Jun 2007 00:02:53 -0000
@@ -214,7 +214,7 @@ _hurdsig_fault_init(void)
__proc_handle_exceptions (port,
sigexc,
forward_sigexc, MACH_MSG_TYPE_MAKE_SEND,
- MACHINE_THREAD_STATE_FLAVR,
+ MACHINE_NEW_THREAD_STATE_FLAVR,
(natural_t *) &state,
MACHINE_THREAD_STATE_****));
assert_perror (err);
Index: mach/setup-thread.c

RCS file: /,v
retrieving revision 1.19
mach/setup-thread.c22 Dec 2005 11:31:24 -00001.19
mach/setup-thread.c12 Jun 2007 00:02:54 -0000
@@ -73,7 +73,7 @@ __mach_setup_thread()
if (error = __vm_protect (task, stack, __vm_page_size, 0, VM_PRT_NNE))
return error;
- return __thread_set_state (thread, MACHINE_THREAD_STATE_FLAVR,
+ return __thread_set_state (thread, MACHINE_NEW_THREAD_STATE_FLAVR,
(natural_t *) &ts, tssize);
}

Index: sysdeps/generic/thread_state.h

RCS file: /,v
retrieving revision 1.2
sysdeps/generic/thread_state.h6 Jul 2001 04:55:50 -00001.2
sysdeps/generic/thread_state.h12 Jun 2007 00:02:54 -0000
@@ -23,6 +23,7 @@

/* Replace <machinewith "i386" or "mips" or whatever. */

+#define MACHINE_NEW_THREAD_STATE_FLAVR<machine>_NEW_THREAD_STATE
#define MACHINE_THREAD_STATE_FLAVR<machine>_THREAD_STATE
#define MACHINE_THREAD_STATE_****<machine>_THREAD_STATE_****

Index:

RCS file: /,v
retrieving revision 1.5
6 Jul 2001 04:55:56 -00001.5
12 Jun 2007 00:02:54 -0000
@@ -19,6 +19,7 @@

#include <mach/machine/thread_status.h>

+#define MACHINE_NEW_THREAD_STATE_FLAVRALPHA_THREAD_STATE
#define MACHINE_THREAD_STATE_FLAVRALPHA_THREAD_STATE
#define MACHINE_THREAD_STATE_****ALPHA_THREAD_STATE_****

Index:

RCS file: /,v
retrieving revision 1.14
6 Jul 2001 04:56:00 -00001.14
12 Jun 2007 00:02:54 -0000
@@ -19,7 +19,8 @@

#include <mach/machine/thread_status.h>
-#define MACHINE_THREAD_STATE_FLAVRi386_THREAD_STATE
+#define MACHINE_NEW_THREAD_STATE_FLAVRi386_THREAD_STATE
+#define MACHINE_THREAD_STATE_FLAVRi386_REGS_SEGS_STATE
#define MACHINE_THREAD_STATE_****i386_THREAD_STATE_****

#define machine_thread_state i386_thread_state
Index:

RCS file: /,v
retrieving revision 1.2
26 Aug 2002 22:39:44 -00001.2
12 Jun 2007 00:02:54 -0000
@@ -19,6 +19,7 @@

#include <mach/machine/thread_status.h>

+#define MACHINE_NEW_THREAD_STATE_FLAVRPPC_THREAD_STATE
#define MACHINE_THREAD_STATE_FLAVRPPC_THREAD_STATE
#define MACHINE_THREAD_STATE_****PPC_THREAD_STATE_****

2007-06-23 19:27:14.000000000 +0000
2007-06-23 21:41:40.000000000 +0000
@@ -116,14 +116,14 @@
/* If we are the bootstrap task started by the kernel,
then after the environment pointers there is no Hurd
data block; the argument strings start there. */
- if ((void *) d == argv[0])
+ if ((void *) d == argv[0] || !d->phdr)
{
#ifndef SHARED
/* We may need to see our own phdrs, e.g. for TLS setup.
Try the usual kludge to find the headers without help from
the exec server. */
- extern const void _start;
- const ElfW(Ehdr) *const ehdr = &_start;
+ extern const void __executable_start;
+ const ElfW(Ehdr) *const ehdr = &__executable_start;
_dl_phdr = (ElfW(Phdr) *) ((const void *) ehdr + ehdr->e_phoff);
_dl_phnum = ehdr->e_phnum;
assert (ehdr->e_phentsize == sizeof (ElfW(Phdr)));

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Follow-up Comment #13, bug #17644 (project hurd):

, 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)

Additional Item Attachment:

File name: patch-hurd-tls-transitional Size:12 KB

Reply to this item at:

<>

Message via/par Savannah
http://savannah.gnu.org/

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Sun, Jun 24, 2007 at 02:09:13PM +0000, Samuel Thibault wrote:
Here are updated patches, ext2fs.static now works. mach-defpager doesn't,
however.

I get "Assertion `ports->ip_srights 0' failed in file
"/ipc/ipc_right.c", line 1411" when I run your hurd/libc0.3 packages
in qemu, see the attached screenshot.

Michael

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

Hello!

Wed, Jul 04, 2007 at 05:19:59PM +0200, Michael Banck wrote:
Sun, Jun 24, 2007 at 02:09:13PM +0000, Samuel Thibault wrote:
Here are updated patches, ext2fs.static now works. mach-defpager doesn't,
however.

I get "Assertion `ports->ip_srights 0' failed in file
"/ipc/ipc_right.c", line 1411" when I run your hurd/libc0.3 packages
in qemu, see the attached screenshot.

As already reported in #hurd at the time that Samuel had published his
packages, I had been hitting that one: ``Assertion `table != IPR_NULL'
failed in file "", line 245''.

Regards,
Thomas

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

+KMXr61fQHV2yXa9oos=
=3yKC
PGP SIGNATURE

Wed, Jul 04, 2007 at 06:22:05PM +0200, Thomas Schwinge wrote:
Hello!

Wed, Jul 04, 2007 at 05:19:59PM +0200, Michael Banck wrote:
Sun, Jun 24, 2007 at 02:09:13PM +0000, Samuel Thibault wrote:
Here are updated patches, ext2fs.static now works. mach-defpager doesn't,
however.

I get "Assertion `ports->ip_srights 0' failed in file
"/ipc/ipc_right.c", line 1411" when I run your hurd/libc0.3 packages
in qemu, see the attached screenshot.

As already reported in #hurd at the time that Samuel had published his
packages, I had been hitting that one: ``Assertion `table != IPR_NULL'
failed in file "", line 245''.

Ah, ok. So far, I only ever hit a general protection fault or a hang
(the latter was also report by Buddenhagen). I now tried on yet
another real machine (a Duron 800) and got the same assertion as you did
there.

Michael

Bug-hurd mailing list
Bug-hurd (AT) gnu (DOT) org