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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils