Re: SIGSEGV in ld at elflink.h:5500

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Wed, Jul 17, 2002 at 12:39:24AM -0400, John David Anglin wrote:
> > but I am puzzled why the R_PARISC_DIR32 don't cause a similar problem.
> 
> Because elf32_hppa_check_relocs has this code
> 
>       if (need_entry & NEED_DYNREL)
> 	{
> .
> .
> 	  if (...
> 	       && (sec->flags & SEC_ALLOC) != 0
> 
> and similarly elsewhere.  elf32-hppa doesn't emit dynamic relocs for
> debugging sections.

I don't think this is the problem.  As far as I can tell, we are
not emitting dynamic relocs for the debugging sections.

If you look back at the original report, you will see that the
".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section has its output_section
set to the bfd_abs_section.  It has SEC_ALLOC set in its flags
and SEC_EXCLUDE is not set.  It has a nonzero size.  Thus, the
only apparent reason that the output_section for this section
is set to the bfd_abs_section is that there are multiple copies
of this weak function/section.  Looking at the .o source files,
there appear to be four input objects containing this weak
function.

There are a couple of possibilities for the symbol reference
that causes the problem.  I know that the reloc is local,
from the .data section, from io-inst.o.  The SEC_ALLOC is
set in the flags of the .data section when the symbol is put
onto the dynlocal list.

We have the following assembly code for for _ZTv0_n24_NSdD1Ev in io-inst.s:

        .IMPORT _ZTv0_n24_NSdD1Ev,ENTRY
	.section        .gnu.linkonce.t._ZTv0_n24_NSdD1Ev,"ax",@progbits
	.align 8
	.weak   _ZTv0_n24_NSdD1Ev
	.EXPORT _ZTv0_n24_NSdD1Ev,ENTRY
L$FB1521
	.loc 40 64 0
_ZTv0_n24_NSdD1Ev
	.PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
L$CFI0122
	...

The symbol that causes the problem comes from io-inst.o.  io-inst.o
is the owner of the ".gnu.linkonce.t._ZTv0_n24_NSdD1Ev" section that
causes the seg fault.  The most likely symbol is a reference to
L$FB1521 in the .data section:

L$SFDE0073
        .word   L$EFDE0073-L$ASFDE0073
L$ASFDE0073
	.word   L$ASFDE0073-L$frame0001
	.dword  L$FB1521
	.dword  L$FE1521-L$FB1521
	...

This is code is not present without eh information, so we have the
link with enabling eh frame information.  The above is also consistent
with the DIR64 reloc.

So, what do we do?  We have have a reference in the data section
to a local label in a function that has been deleted.  On hppa-linux,
the above data is in .eh_frame.  Is it somehow special?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)