[Bug ld/22721] [2.30, 2.31 regression] Solaris/x86 TLS transition failures with linker plugin

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://sourceware.org/bugzilla/show_bug.cgi?id=22721

--- Comment #6 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
[...]
> Please do
>
> 1. Get users/hjl/lto-mixed/master branch and build/install it.
> 2. Pass -v -save-temps -Wl,-plugin-save-temps to gcc
> This should save all temporary files used by ld LTO.
> 3. Create .gdbinit to set environment variables used by ld LTO with
> output from "gcc -v".
> 4. Capture the failed ld LTO command line option.
> 5. Run ld under gdb to investigate why ld fails.

I did some digging so far.  That branch didn't include the culprit
patch.  If I use gld build from it as is, the testcase works fine.
Next, I've applied that patch and could reproduced the failure, so the
reghunt was correct in identifying the culprit.

I find that this call to elf_i386_check_tls_transition returns FALSE

Thread 2 hit Breakpoint 2, elf_i386_check_tls_transition (sec=0x8303f48,
contents=0x82b6c78 "U\211\345\213E\b]\303U\211\345S\203\354\024\307E\364",
symtab_hdr=0x82fa2ac, sym_hashes=0x83050f4, r_type=18, rel=0x8305184,
relend=0x83051b4) at /var/gcc/reghunt/binutils-lto-mixed/bfd/elf32-i386.c:1381

here:

      h = sym_hashes[r_symndx - symtab_hdr->sh_info];
      if (h == NULL
          || !((struct elf_i386_link_hash_entry *) h)->tls_get_addr)
        return FALSE;

(gdb) p *$33
$34 = {elf = {root = {root = {next = 0x0, string = 0x846d570
"___tls_get_addr@@SUNWprivate_1.1", hash = 624670595}, type =
bfd_link_hash_defined, non_ir_ref_regular = 0, non_ir_ref_dynamic = 0,
linker_def = 0, ldscript_def = 0, u = {undef = {next = 0x846d594, abfd =
0x82d88d4}, def = {next = 0x846d594, section = 0x82d88d4, value = 1081620}, i =
{next = 0x846d594, link = 0x82d88d4, warning = 0x108114 <error: Cannot access
memory at address 0x108114>}, c = {next = 0x846d594, p = 0x82d88d4, size =
1081620}}}, indx = -1, dynindx = 8, got = {refcount = 0, offset = 0, glist =
0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0},
size = 45, type = 2, other = 0, target_internal = 0, ref_regular = 1,
def_regular = 0, ref_dynamic = 0, def_dynamic = 1, ref_regular_nonweak = 1,
dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, versioned =
versioned, forced_local = 0, dynamic = 0, mark = 0, non_got_ref = 0,
dynamic_def = 1, ref_dynamic_nonweak = 0, pointer_equality_needed = 0,
unique_global = 0, protected_def = 0, start_stop = 0, dynstr_index = 9, u =
{weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x82da720, vertree =
0x82da720}, u2 = {start_stop_section = 0x0, vtable = 0x0}}, dyn_relocs = 0x0,
tls_type = 0 '\000', gotoff_ref = 0, has_got_reloc = 0, has_non_got_reloc = 0,
no_finish_dynamic_symbol = 0, tls_get_addr = 0, func_pointer_refcount = 0,
plt_got = {refcount = -1, offset = 18446744073709551615, glist = 0xffffffff,
plist = 0xffffffff}, plt_second = {refcount = 0, offset = 0, glist = 0x0, plist
= 0x0}, tlsdesc_got = 18446744073709551615}

It's pretty obvious that this *is* ___tls_get_addr, but h->tls_get_addr
is 0 nontheless.

        Rainer

-- 
You are receiving this mail because:
You are on the CC list for the bug.