This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: SIGSEGV in ld at elflink.h:5500
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: amodra at bigpond dot net dot au (Alan Modra)
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 17 Jul 2002 00:39:24 -0400 (EDT)
- Subject: Re: SIGSEGV in ld at elflink.h:5500
> Looking at your original email again.. :) I see that what's happening
> is that you're trying to output a dynamic symbol from a removed
> linkonce section. You need to find why ld is trying to do that, or in
> fact why ld is outputting dynamic symbols for debugging sections.
Comparing the object files for string-inst.o with and without eh
frame info, the main difference in section information appears to
be that the file with eh frame info has a .debug_frame section
that the other doesn't have. It has relocations like
RELOCATION RECORDS FOR [.debug_frame]:
OFFSET TYPE VALUE
0000000000000014 R_PARISC_SECREL32 .debug_frame
0000000000000018 R_PARISC_DIR64 .gnu.linkonce.t._ZNKSs7_M_dataEv
000000000000003c R_PARISC_SECREL32 .debug_frame
0000000000000040 R_PARISC_DIR64 .gnu.linkonce.t._ZNSs7_M_dataEPc
...
The hppa-linux 32-bit relocations are
RELOCATION RECORDS FOR [.debug_frame]:
OFFSET TYPE VALUE
00000014 R_PARISC_DIR32 .debug_frame
00000018 R_PARISC_DIR32 .gnu.linkonce.t._ZNKSs7_M_dataEv
00000024 R_PARISC_DIR32 .debug_frame
00000028 R_PARISC_DIR32 .gnu.linkonce.t._ZNSs7_M_dataEPc
...
I would guess that's the R_PARISC_DIR64 relocs that are the problem
but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)