https://sourceware.org/bugzilla/show_bug.cgi?id=30697
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
Target| |powerpc-linux
Status|NEW |ASSIGNED
CC|amodra at gmail dot com |
--- Comment #2 from Alan Modra <amodra at gmail dot com> ---
Looking at the broken libpython3.12.so, I see lots of code similar to the
following
2c64d4: 38 69 ff f8 addi r3,r9,-8
2c64d8: 48 0d 65 89 bl 39ca60
<00008000.got2.plt_pic32.__tls_get_addr_opt@@GLIBC_2.22+0x420>
2c64dc: 3c 63 00 00 addis r3,r3,0
2c64e0: 38 63 80 04 addi r3,r3,-32764
The addis,addi looks correct to me. _Py_tss_tstate is at offset 4 in TLS, and
the dtv offset is 0x8000.
0057fff0 0 OBJECT LOCAL DEFAULT 20 _GLOBAL_OFFSET_TABLE_
and
libpython3.12.so: file format elf32-powerpc
Contents of section .got:
57ffdc 00000044 00000000 00000000 00000000 ...D............
57ffec 00000000 0057fedc 00000000 00000000 .....W..........
says that tls_get_addr_opt is being called with r3 = 57ffe8. Looking at
dynamic relocs shows a DTPMOD32/DTPREL32 pair at 57ffe0 (for a global dynamic
access to _Py_tss_tstate as it happens), but nothing at 57ffe8. So the stub
calling tls_get_addr_opt sees a zero in the first word of the tls_index pair,
and returns a zero offset from r2 (the thread pointer). That's wrong (by
0x1000 in this particular testcase).
The first word of the tls_index pair at 57ffe8 should have a DTPMOD32 dynamic
reloc since this is in a shared library and therefore the module index is
unknown. (In an executable the word could be initialised to 1.)
--
You are receiving this mail because:
You are on the CC list for the bug.
