diff options
author | James Clarke <jrtc27@jrtc27.com> | 2017-10-13 15:44:39 -0300 |
---|---|---|
committer | Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com> | 2017-10-13 16:14:16 -0300 |
commit | 8644588807215ab09716ac04a150f91ac83acffd (patch) | |
tree | a102e789349ae949df505458c19b41abf5f327d2 /nptl/allocatestack.c | |
parent | e8dbd6a36d8e4d30e736e28a364f7a4d1404079a (diff) | |
download | glibc-8644588807215ab09716ac04a150f91ac83acffd.tar.gz glibc-8644588807215ab09716ac04a150f91ac83acffd.tar.xz glibc-8644588807215ab09716ac04a150f91ac83acffd.zip |
Fix TLS relocations against local symbols on powerpc32, sparc32 and sparc64
Normally, TLS relocations against local symbols are optimised by the linker to be absolute. However, gold does not do this, and so it is possible to end up with, for example, R_SPARC_TLS_DTPMOD64 referring to a local symbol. Since sym_map is left as null in elf_machine_rela for the special local symbol case, the relocation handling thinks it has nothing to do, and so the module gets left as 0. Havoc then ensues when the variable in question is accessed. Before this fix, the main_local_gold program would receive a SIGBUS on sparc64, and SIGSEGV on powerpc32. With this fix applied, that test now passes like the rest of them. * sysdeps/powerpc/powerpc32/dl-machine.h (elf_machine_rela): Assign sym_map to be map for local symbols, as TLS relocations use sym_map to determine whether the symbol is defined and to extract the TLS information. * sysdeps/sparc/sparc32/dl-machine.h (elf_machine_rela): Likewise. * sysdeps/sparc/sparc64/dl-machine.h (elf_machine_rela): Likewise.
Diffstat (limited to 'nptl/allocatestack.c')
0 files changed, 0 insertions, 0 deletions