This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
ld segfault on incrementally linked object
- To: binutils at sources dot redhat dot com
- Subject: ld segfault on incrementally linked object
- From: "Ryan Bedwell (ra9407)" <ra9407 at email dot sps dot mot dot com>
- Date: Thu, 10 May 2001 22:16:00 -0500
- Organization: Motorola - SPS - IES - MSD
- Reply-To: ryan dot bedwell at motorola dot com
Hello!
I'm seeing a bit of strange behavior: I'm getting ld segfaults, and I've
narrowed it down to unresolved symbols in an object file which was
created by incrementally linking several other object files. However,
if I specify the source object files rather than the incrementally
linked file, it correctly reports the unresolved symbols and exits.
I've seen this in the 2.10 and 2.10.1 binutils releases (I'm
cross-compiling for a powerpc-eabi target with dwarf debugging info from
a Sun Solaris host). Here's a gdb stack trace from the failure (2.10.1
sources):
Program received signal SIGSEGV, Segmentation fault.
bfd_getb16 (addr=0x2745d9 <Address 0x2745d9 out of bounds>) at
libbfd.c:925
925 return (addr[0] << 8) | addr[1];
(gdb) where
#0 bfd_getb16 (addr=0x2745d9 <Address 0x2745d9 out of bounds>) at
libbfd.c:925
#1 0x555f4 in parse_die (abfd=0xb9388, aDieInfo=0xffbeefa0,
aDiePtr=0x2745db <Address 0x2745db out of bounds>) at dwarf1.c:211
#2 0x55930 in parse_functions_in_unit (stash=0xc3a08, aUnit=0xc3a50)
at dwarf1.c:357
#3 0x55a3c in dwarf1_unit_find_nearest_line (stash=0xc3a08,
aUnit=0xc3a50,
addr=300, filename_ptr=0xffbef1cc, functionname_ptr=0xffbef1c8,
linenumber_ptr=0xffbef1c4) at dwarf1.c:414
#4 0x55c18 in _bfd_dwarf1_find_nearest_line (abfd=0xb9388,
section=0xc07c0,
symbols=0x1b2df0, offset=300, filename_ptr=0xffbef1cc,
functionname_ptr=0xffbef1c8, linenumber_ptr=0xffbef1c4) at
dwarf1.c:562
#5 0x527cc in _bfd_elf_find_nearest_line (abfd=0xb9388,
section=0xbdec0,
symbols=0x1b2df0, offset=300, filename_ptr=0xffbef1cc,
functionname_ptr=0xffbef1c8, line_ptr=0xffbef1c4) at elf.c:4783
#6 0x2d278 in vfinfo (fp=0xa5d40,
fmt=0x822ca ": undefined reference to `%T'\n", arg=0xffbef3dc)
at ldmisc.c:305
#7 0x2d784 in einfo (fmt=0x822c8 "%C: undefined reference to `%T'\n")
at ldmisc.c:455
#8 0x2a350 in undefined_symbol (info=0xa5000,
name=0xc1026 "mpc8260_icache_state", abfd=0xb9388, section=0xbdec0,
address=300, fatal=true) at ./ldmain.c:1207
#9 0x401f0 in ppc_elf_relocate_section (output_bfd=0xae330,
info=0xa5b98,
input_bfd=0xb9388, input_section=0xbdec0,
contents=0x1630b8 "\224!ÿà|\b\002¦\223A", relocs=0xc26ec,
local_syms=0x1abcb0, local_sections=0x1b0dc8) at elf32-ppc.c:3117
#10 0x49f5c in elf_link_input_bfd (finfo=0xffbef600, input_bfd=0xb9388)
at elflink.h:5489
#11 0x48464 in bfd_elf32_bfd_final_link (abfd=0xae330, info=0xa5b98)
at elflink.h:4392
#12 0x4b598 in _bfd_elf32_gc_common_final_link (abfd=0xae330,
info=0xa5b98)
at elflink.h:6677
#13 0x2aef8 in ldwrite () at ldwrite.c:519
#14 0x28edc in main (argc=530432, argv=0xffbef80c) at ./ldmain.c:367
(gdb)
Any ideas?
Thanks,
Ryan