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

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

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.

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

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.000

[bug #17644] glibc: support for TLS

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: __

[bug #17644] glibc: support for TLS

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

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

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

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

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

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

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 at

[bug #17644] glibc: support for TLS

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 transit

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

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: Fir

[bug #17644] glibc: support for TLS

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

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

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.

[bug #17644] glibc: support for TLS

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 li

[bug #17644] glibc: support for TLS

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

[bug #17644] glibc: support for TLS

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-transit

[bug #17644] glibc: support for TLS

Additional Item Attachment, bug #17644 (project hurd): File name: patch-hurd-tls-transitionalSize:7 KB ___ Reply to this item at: ___ Message post

[bug #17644] glibc: support for TLS

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

[bug #17644] glibc: support for TLS

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)

[bug #17644] glibc: support for TLS

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)

[bug #17644] glibc: support for TLS

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:

[bug #17644] glibc: support for TLS

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:

[bug #17644] glibc: support for TLS

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:

[bug #17644] glibc: support for TLS

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

[bug #17644] glibc: support for TLS

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

[bug #17644] glibc: support for TLS

Follow-up Comment #1, bug #17644 (project hurd): Some links: ___ Reply to this item at: