(gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/dave/gnu/binutils/objdir/ld/.libs/ld-new -plugin /usr/lib/gcc/hppa-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/hppa-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=-debug.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o .libs/poly /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crt1.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crti.o /usr/lib/gcc/hppa-linux-gnu/7/crtbegin.o -L/usr/lib/gcc/hppa-linux-gnu/7 -L/usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu -L/usr/lib/gcc/hppa-linux-gnu/7/../../.. -L/lib/hppa-linux-gnu -L/usr/lib/hppa-linux-gnu --as-needed polyexport.o libpolymain/.libs/libpolymain.a libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/hppa-linux-gnu/7/crtend.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crtn.o GNU ld (GNU Binutils) 2.29.51.20170819 Breakpoint 2, elf32_hppa_relocate_section (output_bfd=0x0, info=0x71684 <link_info>, input_bfd=0xf887405b <bfd_bwrite+84>, input_section=0xa5a18, contents=<optimized out>, relocs=<optimized out>, local_syms=<optimized out>, local_sections=<optimized out>) at ../../src/bfd/elf32-hppa.c:4055 4055 abort (); (gdb) p *input_section $2 = {name = 0xa438b ".data", id = 60, index = 4, next = 0xa5ad0, prev = 0xa5960, flags = 295, user_set_vma = 1, linker_mark = 1, linker_has_input = 0, gc_mark = 0, compress_status = 0, segment_mark = 0, sec_info_type = 0, use_rela_p = 1, sec_flg0 = 0, sec_flg1 = 0, sec_flg2 = 0, sec_flg3 = 0, sec_flg4 = 0, sec_flg5 = 0, vma = 0, lma = 0, size = 4920, rawsize = 0, compressed_size = 0, relax = 0x0, relax_count = 0, output_offset = 24368, output_section = 0x552958, alignment_power = 3, relocation = 0x0, orelocation = 0x0, reloc_count = 167, filepos = 7931160, rel_filepos = 4019104, line_filepos = 0, userdata = 0x0, contents = 0x0, lineno = 0x0, lineno_count = 0, entsize = 0, kept_section = 0x0, moving_line_filepos = 0, target_index = 0, used_by_bfd = 0xa78e0, constructor_chain = 0x0, owner = 0xa46a8, symbol = 0xa7970, symbol_ptr_ptr = 0xa5ab0, map_head = {link_order = 0xa5ad0, s = 0xa5ad0}, map_tail = {link_order = 0xa5960, s = 0xa5960}} (gdb) p *((struct bfd_elf_section_data*)(input_section)->used_by_bfd) $3 = {this_hdr = {sh_name = 19, sh_type = 1, sh_flags = 3, sh_addr = 0, sh_offset = 7931160, sh_size = 4920, sh_link = 0, sh_info = 0, sh_addralign = 8, sh_entsize = 0, bfd_section = 0xa5a18, contents = 0x0}, section_flag_info = 0x0, rel = {hdr = 0x0, count = 0, idx = 0, hashes = 0x0}, rela = {hdr = 0xa79a8, count = 0, idx = 0, hashes = 0x0}, this_idx = 11, dynindx = 0, linked_to = 0x0, relocs = 0xa7ec8, local_dynrel = 0x0, sreloc = 0x0, group = {name = 0x0, id = 0x0}, sec_group = 0x0, next_in_group = 0x0, fde_list = 0x0, eh_frame_entry = 0x0, sec_info = 0x0} Full polyml build log is here: https://buildd.debian.org/status/fetch.php?pkg=polyml&arch=hppa&ver=5.7-2&stamp=1507223380&raw=0
Have you tried with current HEAD? A couple of patches have gone in that may be relevant, 46434633f9c and 559192d89d7.
Will check. I thought the debug info that I posted was for the trunk but I see it was for "GNU ld (GNU Binutils) 2.29.51.20170819".
On 2017-10-15, at 7:57 PM, amodra at gmail dot com wrote: > Have you tried with current HEAD? Same error occurs with current head. Starting program: /home/dave/gnu/binutils/objdir/ld/.libs/ld-new -plugin /usr/lib/gcc/hppa-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/hppa-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=-debug.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld.so.1 -o .libs/poly /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crt1.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crti.o /usr/lib/gcc/hppa-linux-gnu/7/crtbegin.o -L/usr/lib/gcc/hppa-linux-gnu/7 -L/usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu -L/usr/lib/gcc/hppa-linux-gnu/7/../../.. -L/lib/hppa-linux-gnu -L/usr/lib/hppa-linux-gnu --as-needed polyexport.o libpolymain/.libs/libpolymain.a libpolyml/.libs/libpolyml.so -lpthread -lffi -lm -ldl -lstdc++ -lgcc_s -lgcc -v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/hppa-linux-gnu/7/crtend.o /usr/lib/gcc/hppa-linux-gnu/7/../../../hppa-linux-gnu/crtn.o GNU ld (GNU Binutils) 2.29.51.20171016 /home/dave/gnu/binutils/objdir/ld/.libs/ld-new: BFD (GNU Binutils) 2.29.51.20171016 internal error, aborting at ../../src/bfd/elf32-hppa.c:3937 in elf32_hppa_relocate_section -- John David Anglin dave.anglin@bell.net
p *hh $6 = {eh = {root = {root = {next = 0x288fa0, string = 0x14ede2 "PolyThreadForkThread", hash = 155903331}, type = bfd_link_hash_defined, non_ir_ref_regular = 0, non_ir_ref_dynamic = 0, linker_def = 0, ldscript_def = 0, u = { undef = {next = 0x12fb18, abfd = 0x1581f8}, def = {next = 0x12fb18, section = 0x1581f8, value = 225876}, i = { next = 0x12fb18, link = 0x1581f8, warning = 0x37254 <gldhppalinux_search_needed+532> "\b\003\002Z\350X\n\255\b\006\002C\350X\n\235\b\021\002Z4\031"}, c = { next = 0x12fb18, p = 0x1581f8, size = 225876}}}, indx = -1, dynindx = 39, got = {refcount = -1, offset = 4294967295, glist = 0xffffffff, plist = 0xffffffff}, plt = {refcount = -1, offset = 4294967295, glist = 0xffffffff, plist = 0xffffffff}, size = 604, 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 = 1, needs_copy = 0, needs_plt = 0, non_elf = 1, versioned = unversioned, 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 = 1527, u = { weakdef = 0xde9f7f4, elf_hash_value = 233437172}, verinfo = {verdef = 0x0, vertree = 0x0}, u2 = {start_stop_section = 0x0, vtable = 0x0}}, hsh_cache = 0x0, dyn_relocs = 0x0, tls_type = GOT_UNKNOWN, plabel = 0} Huh, non_elf set? So that comes about due to _bfd_elf_merge_symbol not getting to elflink.c:1212 where non_elf is cleared. And if we don't get there then none of the proper merging of elf symbols occurs. And that's because _bfd_elf_merge_symbol exits here: if (!(*bed->relocs_compatible) (abfd->xvec, info->output_bfd->xvec)) return TRUE; The output bfd vec is hppa_elf32_linux_vec while the input (polyexport.o) is hppa_elf32_vec, and elf32-hppa.c has no define for elf_backend_relocs_compatible so uses the default that requires an exact match of bfd vec. polyexport.o is hppa_elf32_vec because os/abi is ELFOSABI_HPUX. The output is hppa_elf32_linux_vec because that's the default target. bug 1: polyimport, the producer of polyexport.o is using the wrong os/abi for hppa-linux. bug 2: elf32-hppa.c ought to be using _bfd_elf_relocs_compatible bug 3: _bfd_elf_merge_symbol shouldn't be using relocs_compatible
The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c0e331c794d6bd75d9be9bea6145513074c33f39 commit c0e331c794d6bd75d9be9bea6145513074c33f39 Author: Alan Modra <amodra@gmail.com> Date: Sat Oct 28 14:10:55 2017 +1030 PR22300, Abort in elf32_hppa_relocate_section building polyml polyml produces object files with the wrong OS/ABI for hppa-linux. This, along with the fact that elf32-hppa.c is using the strictest backend relocs_compatible, results in wrong merging of ELF symbols. So, remove the relocs_compatible check in _bfd_elf_merge_symbol. _bfd_elf_merge_symbol is only called nowadays from within blocks protected by is_elf_hash_table, so "we are doing an ELF link" as the removed comment says, is true. Also relax relocs_compatible for hppa and powerpc. relocs_compatible is used for more than just merging symbols, as the name suggests. This allows objects that are in fact reasonably compatible to be linked. PR 22300 * elflink.c (_bfd_elf_merge_symbol): Remove relocs_compatible check. * elf32-hppa.c (elf_backend_relocs_compatible): Define. * elf32-ppc.c (elf_backend_relocs_compatible): Define. * elf64-ppc.c (elf_backend_relocs_compatible): Define.
Thanks Alan. That was an excellent bit of debugging. I created a debian bug report for the polyml bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880023 -- John David Anglin dave.anglin@bell.net
The binutils-2_29-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1dac3b4518f811cc124df2040db3c5a0e9049bb3 commit 1dac3b4518f811cc124df2040db3c5a0e9049bb3 Author: Alan Modra <amodra@gmail.com> Date: Sat Oct 28 14:10:55 2017 +1030 PR22300, Abort in elf32_hppa_relocate_section building polyml polyml produces object files with the wrong OS/ABI for hppa-linux. This, along with the fact that elf32-hppa.c is using the strictest backend relocs_compatible, results in wrong merging of ELF symbols. So, remove the relocs_compatible check in _bfd_elf_merge_symbol. _bfd_elf_merge_symbol is only called nowadays from within blocks protected by is_elf_hash_table, so "we are doing an ELF link" as the removed comment says, is true. Also relax relocs_compatible for hppa and powerpc. relocs_compatible is used for more than just merging symbols, as the name suggests. This allows objects that are in fact reasonably compatible to be linked. PR 22300 * elflink.c (_bfd_elf_merge_symbol): Remove relocs_compatible check. * elf32-hppa.c (elf_backend_relocs_compatible): Define. * elf32-ppc.c (elf_backend_relocs_compatible): Define. * elf64-ppc.c (elf_backend_relocs_compatible): Define. (cherry picked from commit c0e331c794d6bd75d9be9bea6145513074c33f39)
Fixed