diff options
author | Alexandre Oliva <aoliva@redhat.com> | 2016-09-21 22:01:16 -0300 |
---|---|---|
committer | Alexandre Oliva <aoliva@redhat.com> | 2016-09-21 22:01:16 -0300 |
commit | 17af5da98cd2c9ec958421ae2108f877e0945451 (patch) | |
tree | 6f1e45cb0947ef6c28d931f9c07b5a0f1292885c /iconvdata/ibm1132.h | |
parent | 444eacba82f675d4657ad55da67b355536be90ab (diff) | |
download | glibc-17af5da98cd2c9ec958421ae2108f877e0945451.tar glibc-17af5da98cd2c9ec958421ae2108f877e0945451.tar.gz glibc-17af5da98cd2c9ec958421ae2108f877e0945451.tar.bz2 glibc-17af5da98cd2c9ec958421ae2108f877e0945451.zip |
[PR19826] fix non-LE TLS in static programs
An earlier fix for TLS dropped early initialization of DTV entries for
modules using static TLS, leaving it for __tls_get_addr to set them
up. That worked on platforms that require the GD access model to be
relaxed to LE in the main executable, but it caused a regression on
platforms that allow GD in the main executable, particularly in
statically-linked programs: they use a custom __tls_get_addr that does
not update the DTV, which fails when the DTV early initialization is
not performed.
In static programs, __libc_setup_tls performs the DTV initialization
for the main thread, but the DTV of other threads is set up in
_dl_allocate_tls_init, so that's the fix that matters.
Restoring the initialization in the remaining functions modified by
this patch was just for uniformity. It's not clear that it is ever
needed: even on platforms that allow GD in the main executable, the
dynamically-linked version of __tls_get_addr would set up the DTV
entries, even for static TLS modules, while updating the DTV counter.
for ChangeLog
[BZ #19826]
* elf/dl-tls.c (_dl_allocate_tls_init): Restore DTV early
initialization of static TLS entries.
* elf/dl-reloc.c (_dl_nothread_init_static_tls): Likewise.
* nptl/allocatestack.c (init_one_static_tls): Likewise.
Diffstat (limited to 'iconvdata/ibm1132.h')
0 files changed, 0 insertions, 0 deletions