Re: __executable_start (was: [bug #17644] glibc: support for TLS)

2013-05-29 Thread Roland McGrath 
> OK to commit?
> 
>   * sysdeps/mach/hurd/i386/init-first.c (init1): Use
>   __executable_start symbol intsead instead of _start.

OK.

Re: __executable_start (was: [bug #17644] glibc: support for TLS)

2013-05-26 Thread Anatoly A. Kazantsev 
On Sun, 26 May 2013 16:38:23 +0200
Thomas Schwinge  wrote:

> Hi!
> 
> Re-submitting an oldie of Samuel's:
> 
> On Sun, 24 Jun 2007 17:45:35 +0200, Samuel Thibault 
>  wrote:
> > - _start points on the first instruction, not on the elf header.
> >   __executable_start does point on the elf header.
> 
> > --- sysdeps/mach/hurd/i386/init-first.c.orig2007-06-23 
> > 19:27:14.0 +
> > +++ sysdeps/mach/hurd/i386/init-first.c 2007-06-23 21:41:40.0 
> > +
> > @@ -116,14 +116,14 @@
> >/* 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)));
> 
> This is, as far as I can tell, the only such usage of _start in glibc.
> 
> OK to commit?
> 
>   * sysdeps/mach/hurd/i386/init-first.c (init1): Use
>   __executable_start symbol intsead instead of _start.
> 
> diff --git sysdeps/mach/hurd/i386/init-first.c 
> sysdeps/mach/hurd/i386/init-first.c
> index fc3330c..7031ed4 100644
> --- sysdeps/mach/hurd/i386/init-first.c
> +++ sysdeps/mach/hurd/i386/init-first.c
> @@ -125,8 +125,8 @@ init1 (int argc, char *arg0, ...)
>/* 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 = (const void *) ehdr + ehdr->e_phoff;
>_dl_phnum = ehdr->e_phnum;
>assert (ehdr->e_phentsize == sizeof (ElfW(Phdr)));
> 
> 
> Grüße,
>  Thomas


-- 
Regards,
Anatoly


pgpoaCH8MLbmU.pgp
Description: PGP signature

__executable_start (was: [bug #17644] glibc: support for TLS)

2013-05-26 Thread Thomas Schwinge 
Hi!

Re-submitting an oldie of Samuel's:

On Sun, 24 Jun 2007 17:45:35 +0200, Samuel Thibault 
 wrote:
> - _start points on the first instruction, not on the elf header.
>   __executable_start does point on the elf header.

> --- sysdeps/mach/hurd/i386/init-first.c.orig  2007-06-23 19:27:14.0 
> +
> +++ sysdeps/mach/hurd/i386/init-first.c   2007-06-23 21:41:40.0 
> +
> @@ -116,14 +116,14 @@
>/* 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)));

This is, as far as I can tell, the only such usage of _start in glibc.

OK to commit?

* sysdeps/mach/hurd/i386/init-first.c (init1): Use
__executable_start symbol intsead instead of _start.

diff --git sysdeps/mach/hurd/i386/init-first.c 
sysdeps/mach/hurd/i386/init-first.c
index fc3330c..7031ed4 100644
--- sysdeps/mach/hurd/i386/init-first.c
+++ sysdeps/mach/hurd/i386/init-first.c
@@ -125,8 +125,8 @@ init1 (int argc, char *arg0, ...)
   /* 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 = (const void *) ehdr + ehdr->e_phoff;
   _dl_phnum = ehdr->e_phnum;
   assert (ehdr->e_phentsize == sizeof (ElfW(Phdr)));


Grüße,
 Thomas


pgp_HpbhK3R37.pgp
Description: PGP signature

[bug #17644] glibc: support for TLS

2007-07-19 Thread Samuel Thibault 

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

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

Additional Item Attachment:



___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-07-17 Thread Samuel Thibault 

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

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?


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17644] glibc: support for TLS

2007-07-04 Thread Michael Banck 
On Wed, Jul 04, 2007 at 06:22:05PM +0200, Thomas Schwinge wrote:
> Hello!
> 
> On Wed, Jul 04, 2007 at 05:19:59PM +0200, Michael Banck wrote:
> > On Sun, Jun 24, 2007 at 02:09:13PM +, 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 "../gnumach-1-branch/ipc/ipc_port.c", line 245''.

Ah, ok.  So far, I only ever hit a general protection fault or a hang
(the latter was also report by Olaf 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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17644] glibc: support for TLS

2007-07-04 Thread Thomas Schwinge 
Hello!

On Wed, Jul 04, 2007 at 05:19:59PM +0200, Michael Banck wrote:
> On Sun, Jun 24, 2007 at 02:09:13PM +, 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 "../gnumach-1-branch/ipc/ipc_port.c", line 245''.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17644] glibc: support for TLS

2007-07-04 Thread Michael Banck 
On Sun, Jun 24, 2007 at 02:09:13PM +, 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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-24 Thread Samuel Thibault 

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

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

Additional Item Attachment:

File name: patch-hurd-tls-transitionalSize:12 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17644] glibc: support for TLS

2007-06-24 Thread Samuel Thibault 
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_FLAVOR defined to
i386_REGS_SEGS_STATE instead of i386_THREAD_STATE_COUNT, 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_FLAVOR which
is defined to i386_THREAD_STATE_COUNT, 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: /cvs/glibc/libc/hurd/hurdfault.c,v
retrieving revision 1.21
diff -u -p -r1.21 hurdfault.c
--- hurd/hurdfault.c21 Dec 2005 22:16:20 -  1.21
+++ hurd/hurdfault.c12 Jun 2007 00:02:53 -
@@ -214,7 +214,7 @@ _hurdsig_fault_init(void)
  __proc_handle_exceptions (port,
   sigexc,
   forward_sigexc, MACH_MSG_TYPE_MAKE_SEND,
-  MACHINE_THREAD_STATE_FLAVOR,
+  MACHINE_NEW_THREAD_STATE_FLAVOR,
   (natural_t *) &state,
   MACHINE_THREAD_STATE_COUNT));
   assert_perror (err);
Index: mach/setup-thread.c
===
RCS file: /cvs/glibc/libc/mach/setup-thread.c,v
retrieving revision 1.19
--- mach/setup-thread.c 22 Dec 2005 11:31:24 -  1.19
+++ mach/setup-thread.c 12 Jun 2007 00:02:54 -
@@ -73,7 +73,7 @@ __mach_setup_thread()
   if (error = __vm_protect (task, stack, __vm_page_size, 0, VM_PROT_NONE))
 return error;
 
-  return __thread_set_state (thread, MACHINE_THREAD_STATE_FLAVOR,
+  return __thread_set_state (thread, MACHINE_NEW_THREAD_STATE_FLAVOR,
 (natural_t *) &ts, tssize);
 }
 
Index: sysdeps/generic/thread_state.h
===
RCS file: /cvs/glibc/libc/sysdeps/generic/thread_state.h,v
retrieving revision 1.2
--- sysdeps/generic/thread_state.h  6 Jul 2001 04:55:50 -   1.2
+++ sysdeps/generic/thread_state.h  12 Jun 2007 00:02:54 -
@@ -23,6 +23,7 @@
 
 /* Replace  with "i386" or "mips" or whatever.  */
 
+#define MACHINE_NEW_THREAD_STATE_FLAVOR_NEW_THREAD_STATE
 #define MACHINE_THREAD_STATE_FLAVOR_THREAD_STATE
 #define MACHINE_THREAD_STATE_COUNT _THREAD_STATE_COUNT
 
Index: sysdeps/mach/alpha/thread_state.h
===
RCS file: /cvs/glibc/libc/sysdeps/mach/alpha/thread_state.h,v
retrieving revision 1.5
--- sysdeps/mach/alpha/thread_state.h   6 Jul 2001 04:55:56 -   1.5
+++ sysdeps/mach/alpha/thread_state.h   12 Jun 2007 00:02:54 -
@@ -19,6 +19,7 @@
 
 #include 
 
+#define MACHINE_NEW_THREAD_STATE_FLAVORALPHA_THREAD_STATE
 #define MACHINE_THREAD_STATE_FLAVORALPHA_THREAD_STATE
 #define MACHINE_THREAD_STATE_COUNT ALPHA_THREAD_STATE_COUNT
 
Index: sysdeps/mach/i386/thread_state.h
===
RCS file: /cvs/glibc/libc/sysdeps/mach/i386/thread_state.h,v
retrieving revision 1.14
--- sysdeps/mach/i386/thread_state.h6 Jul 2001 04:56:00 -   1.14
+++ sysdeps/mach/i386/thread_state.h12 Jun 2007 00:02:54 -
@@ -19,7 +19,8 @@
 
 #include 
 
-#define MACHINE_THREAD_STATE_FLAVORi386_THREAD_STATE
+#define MACHINE_NEW_THREAD_STATE_FLAVORi386_THREAD_STATE
+#define MACHINE_THREAD_STATE_FLAVORi386_REGS_SEGS_STATE
 #define MACHINE_THREAD_STATE_COUNT i386_THREAD_STATE_COUNT
 
 #define machine_thread_state i386_thread_state
Index: sysdeps/mach/powerpc/thread_state.h
===
RCS file: /cvs/glibc/libc/sysdeps/mach/powerpc/thread_state.h,v
retrieving revision 1.2
--- sysdeps/mach/powerpc/thread_state.h 26 Aug 2002 22:39:44 -  1.2
+++ sysdeps/mach/powerpc/thread_state.h 12 Jun 2007 00:02:54 -
@@ -19,6 +19,7 @@
 
 #include 
 
+#define MACHINE_NEW_THREAD_STATE_FLAVORPPC_THREAD_STATE
 #defi

[bug #17644] glibc: support for TLS

2007-06-24 Thread Samuel Thibault 

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-tlsSize:4 KB
File name: patch-hurd-tls-transitionalSize:14 KB
File name: patch-hurd-tls Size:12 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [bug #17644] glibc: support for TLS

2007-06-13 Thread Samuel Thibault 
Samuel Thibault, le Wed 13 Jun 2007 22:02:07 +, a écrit :
> 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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-13 Thread Samuel Thibault 

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 posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-12 Thread Samuel Thibault 

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 posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-12 Thread Samuel Thibault 

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-transitionalSize:7 KB
File name: patch-hurd Size:7 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-12 Thread Samuel Thibault 

Additional Item Attachment, bug #17644 (project hurd):

File name: patch-hurd-tls-transitionalSize:7 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-12 Thread Samuel Thibault 

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 posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-12 Thread Samuel Thibault 

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 posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2007-06-11 Thread Samuel Thibault 

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-glibcSize:3 KB


___

Reply to this item at:

  

___
  Message posté via/par Savannah
  http://savannah.gnu.org/



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-11-06 Thread Thomas Schwinge 

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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-11-06 Thread Thomas Schwinge 

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

Roland's plan was / is to first make `--without-__thread' 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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-11-06 Thread Thomas Schwinge 

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 OSKit 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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-09-08 Thread Thomas Schwinge 

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

Jeroen Dekkers has been working on this, but stopped his efforts.
* GNU Mach:
http://lists.gnu.org/archive/html/bug-hurd/2005-09/msg00152.html>
* glibc
|  http://www.dekkers.cx/hurd/glibc-tls.patch
|  the fork fix isn't the right one
|  because the define is i386-specific
|  we should probably define a MACHINE_THREAD_STATE_FLAVOR2 to
|  i386_REGS_SEGS_STATE or something, roland will probably know the
|  cleanest solution
|  with that patch you can run programs
|  but dlopen() doesn't work
|  maybe other things don't work either
|  but the basic TLS things work :)

___

Additional Item Attachment:

File name: glibc-tls.patchSize: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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-09-08 Thread Thomas Schwinge 

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
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00

___

Details:

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.







___

Reply to this item at:

  

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




___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd

[bug #17644] glibc: support for TLS

2006-09-08 Thread Thomas Schwinge 

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

Some links:





___

Reply to this item at:

  

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



___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd