bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/23980] powerpc64 ld segfault when linking libc on FreeBSD


From: alfredo.junior at eldorado dot org.br
Subject: [Bug ld/23980] powerpc64 ld segfault when linking libc on FreeBSD
Date: Fri, 14 Dec 2018 13:14:51 +0000

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

--- Comment #2 from Alfredo Dal'Ava JĂșnior <alfredo.junior at eldorado dot 
org.br> ---
Alan,

(In reply to Alan Modra from comment #1)
> > #1  0x0000000000d5a1f8 in ppc64_elf_hide_symbol (info=0x119d208 <link_info>,
> > h=0x804bd64e0, force_local=1) at elf64-ppc.c:6243
> 
> "p *(struct ppc_link_hash_entry *) h" might be useful here, if you can
> recreate the problem.

(gdb) p *(struct ppc_link_hash_entry *) h
$1 = {elf = {root = {root = {next = 0x0, string = 0x804c47e5d
"__libc_interposing", hash = 161532955}, type = bfd_link_hash_undefined,
non_ir_ref_regular = 0, non_ir_ref_dynamic = 0, 
      linker_def = 0, ldscript_def = 0, rel_from_abs = 0, u = {undef = {next =
0x0, abfd = 0x8047d4940}, def = {next = 0x0, section = 0x8047d4940, value = 0},
i = {next = 0x0, 
          link = 0x8047d4940, warning = 0x0}, c = {next = 0x0, p = 0x8047d4940,
size = 0}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist =
0x0, plist = 0x0}, plt = {
      refcount = -1, offset = 18446744073709551615, glist = 0xffffffffffffffff,
plist = 0xffffffffffffffff}, size = 0, type = 0, other = 2, target_internal =
0, ref_regular = 1, 
    def_regular = 0, ref_dynamic = 0, def_dynamic = 0, ref_regular_nonweak = 1,
dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, versioned =
unversioned, forced_local = 1, 
    dynamic = 0, mark = 0, non_got_ref = 0, dynamic_def = 0,
ref_dynamic_nonweak = 0, pointer_equality_needed = 0, unique_global = 0,
protected_def = 0, start_stop = 0, is_weakalias = 0, 
    dynstr_index = 0, u = {alias = 0x0, elf_hash_value = 0}, verinfo = {verdef
= 0x0, vertree = 0x0}, u2 = {start_stop_section = 0x0, vtable = 0x0}}, u =
{stub_cache = 0x0, 
    next_dot_sym = 0x0}, dyn_relocs = 0x100, oh = 0xffffffffffffffff, is_func =
1, is_func_descriptor = 1, fake = 0, adjust_done = 1, save_res = 1,
non_zero_localentry = 1, 
  tls_mask = 255 '\377'}


> 
> > #2  0x0000000000bece39 in elf_link_add_object_symbols (abfd=0x8047d7a80,
> > info=0x119d208 <link_info>) at elflink.c:5020
> 
> Also, "p *abfd" here.  And "p abfd->filename" then (outside of gdb) report
> the output of "file" for this file.  There is some possibility you might be
> attempting to link in a non-ppc64 file somehow.

(gdb) p *abfd
$2 = {filename = 0x802621860 "write.pico", xvec = 0x4a4250
<powerpc_elf64_fbsd_vec>, iostream = 0x804b2a1d8, iovec = 0x463990
<cache_iovec>, lru_prev = 0x801c42000, lru_next = 0x8047d4940, 
  where = 2592, mtime = 0, id = 354, format = bfd_object, direction =
read_direction, flags = 32785, cacheable = 1, target_defaulted = 0, opened_once
= 1, mtime_set = 0, no_export = 0, 
  output_has_begun = 0, has_armap = 0, is_thin_archive = 0, selective_search =
0, is_linker_output = 0, is_linker_input = 1, plugin_format =
bfd_plugin_unknown, lto_output = 0, 
  plugin_dummy_bfd = 0x0, origin = 0, proxy_origin = 0, section_htab = {table =
0x804c71910, newfunc = 0xb9cdf0 <bfd_section_hash_newfunc>, memory =
0x804a14380, size = 4051, count = 11, 
    entsize = 304, frozen = 0}, sections = 0x804c49028, section_last =
0x804c49c08, section_count = 11, archive_pass = 0, start_address = 0,
outsymbols = 0x0, symcount = 0, 
  dynsymcount = 0, arch_info = 0x5456e0 <bfd_powerpc_archs>, arelt_data = 0x0,
my_archive = 0x0, archive_next = 0x0, archive_head = 0x0, nested_archives =
0x0, link = {next = 0x0, 
    hash = 0x0}, tdata = {aout_data = 0x804c4d078, aout_ar_data = 0x804c4d078,
coff_obj_data = 0x804c4d078, pe_obj_data = 0x804c4d078, xcoff_obj_data =
0x804c4d078, 
    ecoff_obj_data = 0x804c4d078, srec_data = 0x804c4d078, verilog_data =
0x804c4d078, ihex_data = 0x804c4d078, tekhex_data = 0x804c4d078, elf_obj_data =
0x804c4d078, 
    mmo_data = 0x804c4d078, sun_core_data = 0x804c4d078, sco5_core_data =
0x804c4d078, trad_core_data = 0x804c4d078, som_data = 0x804c4d078,
hpux_core_data = 0x804c4d078, 
    hppabsd_core_data = 0x804c4d078, sgi_core_data = 0x804c4d078,
lynx_core_data = 0x804c4d078, osf_core_data = 0x804c4d078, cisco_core_data =
0x804c4d078, versados_data = 0x804c4d078, 
    netbsd_core_data = 0x804c4d078, mach_o_data = 0x804c4d078, mach_o_fat_data
= 0x804c4d078, plugin_data = 0x804c4d078, pef_data = 0x804c4d078, pef_xlib_data
= 0x804c4d078, 
    sym_data = 0x804c4d078, any = 0x804c4d078}, usrdata = 0x801c09990, memory =
0x804a14360, build_id = 0x0}


(gdb) p abfd->filename
$3 = 0x802621860 "write.pico"


address@hidden /usr/src]# file
/usr/obj/usr/src/powerpc.powerpc64/lib/libc/write.pico
/usr/obj/usr/src/powerpc.powerpc64/lib/libc/write.pico: ELF 64-bit MSB
relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), with
debug_info, not stripped


> 
> Another useful debug exercise would be to use "watch" on the h->oh field of
> the symbol involved here to see where it is being set to -1.

I'm going to look forward for this, at this point libc package is linking 1281
objects but I could reproduce the segfault with just:

/usr/local/ld -shared -o test.so write.pico writev.pico

Apparently both files are PowerPC64:

address@hidden /usr/obj/usr/src/powerpc.powerpc64/lib/libc]# file write.pico
write.pico: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(FreeBSD), with debug_info, not stripped
address@hidden /usr/obj/usr/src/powerpc.powerpc64/lib/libc]# file
writev.pico
writev.pico: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version
1 (FreeBSD), with debug_info, not stripped

The *.pico where produced by "clang", so I wouldn't discard that a problem in
the object file itself.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]