Bug 2008 - Segfault on IA64, something to do with Unwind and section ordering
Summary: Segfault on IA64, something to do with Unwind and section ordering
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.17
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-09 03:40 UTC by Ian Wienand
Modified: 2005-12-17 21:38 UTC (History)
2 users (show)

See Also:
Host: ia64-unknown-linux-gnu
Target:
Build:
Last reconfirmed:


Attachments
kde object file (6.88 KB, application/x-object)
2005-12-09 03:42 UTC, Ian Wienand
Details
other object file (128.29 KB, application/x-object)
2005-12-09 03:43 UTC, Ian Wienand
Details
unstripped object (54.58 KB, application/x-object)
2005-12-11 23:13 UTC, Ian Wienand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Wienand 2005-12-09 03:40:42 UTC
Hi,

I'm see a segfault when building the attached two object files into a shared
object.  It has something to do with the unwind section and section ordering,
though the details have escaped me.

A debugging session is illustrated below.  This is from CVS just a few moments ago.

Thanks!

-i

(gdb) r  -shared -o test.so mainwindow.o moc_qassistantclient.o
Starting program: /usr/local/bin/ld-cvs -shared -o test.so mainwindow.o
moc_qassistantclient.o

Program received signal SIGSEGV, Segmentation fault.
0x40000000000ceee0 in elf_get_linked_section_vma (p=Variable "p" is not available.
) at ../../binutils-cvs/bfd/elflink.c:7604
7604          return s->output_section->vma + s->output_offset;
(gdb) back
#0  0x40000000000ceee0 in elf_get_linked_section_vma (p=Variable "p" is not
available.
) at ../../binutils-cvs/bfd/elflink.c:7604
#1  0x40000000000cef60 in compare_link_order (a=0x60000000001e5af8,
b=0x60000000001e5b00) at ../../binutils-cvs/bfd/elflink.c:7619
#2  0x20000000000bd1e0 in msort_with_tmp () from /lib/tls/libc.so.6.1
#3  0x20000000000bcf00 in msort_with_tmp () from /lib/tls/libc.so.6.1
#4  0x20000000000bced0 in msort_with_tmp () from /lib/tls/libc.so.6.1
#5  0x20000000000bced0 in msort_with_tmp () from /lib/tls/libc.so.6.1
#6  0x20000000000bcf00 in msort_with_tmp () from /lib/tls/libc.so.6.1
#7  0x20000000000bcf00 in msort_with_tmp () from /lib/tls/libc.so.6.1
#8  0x20000000000bcf00 in msort_with_tmp () from /lib/tls/libc.so.6.1
#9  0x20000000000bcf00 in msort_with_tmp () from /lib/tls/libc.so.6.1
#10 0x20000000000bd380 in qsort () from /lib/tls/libc.so.6.1
#11 0x40000000000cfb60 in bfd_elf_final_link (abfd=0x600000000002a7d0,
info=0x6000000000017518) at ../../binutils-cvs/bfd/elflink.c:7699
#12 0x4000000000091490 in elf64_ia64_final_link (abfd=0x600000000002a7d0,
info=0x6000000000017518) at elf64-ia64.c:4028
#13 0x4000000000039a40 in ldwrite () at ../../binutils-cvs/ld/ldwrite.c:557
#14 0x4000000000033c70 in main (argc=6, argv=0x60000fffffe73478) at
../../binutils-cvs/ld/ldmain.c:468
(gdb) up
#1  0x40000000000cef60 in compare_link_order (a=0x60000000001e5af8,
b=0x60000000001e5b00) at ../../binutils-cvs/bfd/elflink.c:7619
7619      bpos = elf_get_linked_section_vma (*(struct bfd_link_order **)b);
(gdb)  print *(*(struct bfd_link_order **)a).u.indirect.section
$1 = {name = 0x600000000006b12b
".gnu.linkonce.ia64unw._ZThn80_N10MainWindowD0Ev", id = 822, index = 806, next =
0x60000000000f8400,
  prev = 0x60000000000f81d0, flags = 131371, user_set_vma = 1, linker_mark = 1,
linker_has_input = 0, gc_mark = 0, gc_mark_from_eh = 0, segment_mark = 0,
  sec_info_type = 0, use_rela_p = 1, has_tls_reloc = 0, has_gp_reloc = 0,
need_finalize_relax = 0, reloc_done = 0, vma = 0, lma = 0, size = 0, rawsize = 0,
  output_offset = 6816, output_section = 0x600000000003d5d0, alignment_power =
0, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 344288,
  rel_filepos = 0, 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 = 0x60000000000f78d0,
constructor_chain = 0x0, owner = 0x600000000003bcb0,
  symbol = 0x60000000000f7870, symbol_ptr_ptr = 0x60000000000f83c8, map_head =
{link_order = 0x600000000016ecf0, s = 0x600000000016ecf0}, map_tail = {
    link_order = 0x60000000000f7fa0, s = 0x60000000000f7fa0}}
(gdb)  print *(*(struct bfd_link_order **)a).u.indirect.section->owner
$2 = {id = 1, filename = 0x60000fffffe73759 "mainwindow.o", xvec =
0x400000000015e810, iostream = 0x600000000003de10, iovec = 0x4000000000151558,
  cacheable = 1, target_defaulted = 0, lru_prev = 0x6000000000105850, lru_next =
0x600000000002a7d0, where = 283872, opened_once = 1, mtime_set = 0,
  mtime = 0, ifd = 0, format = bfd_object, direction = read_direction, flags =
17, origin = 0, output_has_begun = 0, section_htab = {
    table = 0x600000000003f150, size = 4051, newfunc = @0x400000000016efc0:
0x4000000000067ba0 <bfd_section_hash_newfunc>, memory = 0x600000000003e130},
  sections = 0x600000000003e178, section_last = 0x600000000017cd70,
section_count = 858, start_address = 0, symcount = 0, outsymbols = 0x0,
dynsymcount = 0,
  arch_info = 0x400000000016ad00, no_export = 0, arelt_data = 0x0, my_archive =
0x0, next = 0x0, archive_head = 0x0, has_armap = 0,
  link_next = 0x6000000000105850, archive_pass = 0, tdata = {aout_data =
0x600000000003be20, aout_ar_data = 0x600000000003be20,
    oasys_obj_data = 0x600000000003be20, oasys_ar_data = 0x600000000003be20,
coff_obj_data = 0x600000000003be20, pe_obj_data = 0x600000000003be20,
    xcoff_obj_data = 0x600000000003be20, ecoff_obj_data = 0x600000000003be20,
ieee_data = 0x600000000003be20, ieee_ar_data = 0x600000000003be20,
    srec_data = 0x600000000003be20, ihex_data = 0x600000000003be20, tekhex_data
= 0x600000000003be20, elf_obj_data = 0x600000000003be20,
    nlm_obj_data = 0x600000000003be20, bout_data = 0x600000000003be20, mmo_data
= 0x600000000003be20, sun_core_data = 0x600000000003be20,
    sco5_core_data = 0x600000000003be20, trad_core_data = 0x600000000003be20,
som_data = 0x600000000003be20, hpux_core_data = 0x600000000003be20,
    hppabsd_core_data = 0x600000000003be20, sgi_core_data = 0x600000000003be20,
lynx_core_data = 0x600000000003be20, osf_core_data = 0x600000000003be20,
    cisco_core_data = 0x600000000003be20, versados_data = 0x600000000003be20,
netbsd_core_data = 0x600000000003be20, mach_o_data = 0x600000000003be20,
    mach_o_fat_data = 0x600000000003be20, pef_data = 0x600000000003be20,
pef_xlib_data = 0x600000000003be20, sym_data = 0x600000000003be20,
    any = 0x600000000003be20}, usrdata = 0x6000000000019090, memory =
0x600000000003bdf0}
(gdb)
Comment 1 Ian Wienand 2005-12-09 03:42:04 UTC
Created attachment 787 [details]
kde object file

an object file from qt/kde
Comment 2 Ian Wienand 2005-12-09 03:43:12 UTC
Created attachment 788 [details]
other object file

other object file
Comment 3 H.J. Lu 2005-12-11 01:41:28 UTC
moc_qassistantclient.o has

  [36] .gnu.linkonce.ia64unw._ZN7QShared5derefEv
       IA_64_UNWIND     0000000000000000  00000000000017c0  39
       0000000000000018 0000000000000000  39                8
       [0000000000000282]: ALLOC, LINK ORDER, GROUP
  [37] .rela.gnu.linkonce.ia64unw._ZN7QShared5derefEv
       RELA             0000000000000000  0000000000007060  88
       0000000000000048 0000000000000018  36                8
       [0000000000000000]:
  [38] .gnu.linkonce.t._Z7qstrcmpPKcS0_
       PROGBITS         0000000000000000  00000000000017e0  0
       00000000000001c0 0000000000000000  0                 16
       [0000000000000206]: ALLOC, EXEC, GROUP
  [39] .rela.gnu.linkonce.t._Z7qstrcmpPKcS0_
       RELA             0000000000000000  00000000000070a8  88
       0000000000000018 0000000000000018  38                8
       [0000000000000000]:

sh_link of .gnu.linkonce.ia64unw._ZN7QShared5derefEv is 39, which points to
.rela.gnu.linkonce.t._Z7qstrcmpPKcS0_. It looks like moc_qassistantclient.o may
be generated by "strip -g", which triggers bug 1991. The input is bogus. But
linker should try to avoid crash. I will see what I can do.
Comment 4 H.J. Lu 2005-12-11 01:42:48 UTC
Ian, could you please provide the unstripped mainwindow.o and
moc_qassistantclient.o?
Comment 5 Ian Wienand 2005-12-11 23:13:24 UTC
Created attachment 797 [details]
unstripped object
Comment 6 Ian Wienand 2005-12-11 23:16:34 UTC
As you identified, the root cause does appear to be a slightly older strip. 
Using the CVS version doesn't create an object that makes ld segfault.

$ ld-cvs -shared -o test.so moc_qassistantclient-unstripped.o ./mainwindow.o

$ cp moc_qassistantclient-unstripped.o moc_qassistantclient.o

$ strip-cvs --version
GNU strip 2.16.91 20051208
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

$ strip-cvs -g ./moc_qassistantclient.o

$ ld-cvs -shared -o test.so moc_qassistantclient.o ./mainwindow.o

$ cp moc_qassistantclient-unstripped.o moc_qassistantclient.o

$ strip --version
GNU strip 2.16.91 20051206 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

$ strip -g ./moc_qassistantclient.o

$ ld-cvs -shared -o test.so moc_qassistantclient.o ./mainwindow.o
Segmentation fault
Comment 7 H.J. Lu 2005-12-12 15:00:55 UTC
A patch is posted at

http://sourceware.org/ml/binutils/2005-12/msg00100.html
Comment 8 H.J. Lu 2005-12-17 21:38:31 UTC
Fixed.