Re: SIGSEGV in ld at elflink.h:5500

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

> On Tue, Jul 16, 2002 at 08:34:40PM -0400, John David Anglin wrote:
> > Looking at the history of the above, I see that the bug being fixed
> > had sym_sec->output_section set to bfd_abs_section.  The code in this
> > case was also being compiled with "-ffunction-sections" and we seem to
> > have the same problem, but on hppa64.
> 
> 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.

This could be the definition for ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:

/* Handle special EH pointer encodings.  Absolute, pc-relative, and
   indirect are handled automatically.  Since pc-relative encoding is
   not possible on the PA and we don't have the infrastructure for
   data relative encoding, we use aligned plabels for global function
   pointers.  */
#define ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX(FILE, ENCODING, SIZE, ADDR, DONE) \
  do {                                                                  \
    if (((ENCODING) & 0x0F) == DW_EH_PE_aligned)                        \
      {                                                                 \
	fputs (integer_asm_op (SIZE, FALSE), FILE);                     \
	fputs ("P%", FILE);                                             \
	assemble_name (FILE, XSTR (ADDR, 0));                           \
	goto DONE;                                                      \
      }                                                                 \
    } while (0)

However, I didn't think that this is the problem since this still appears
to work under hppa-linux.  As far as I can tell, the only uses of the
above is to obtain the address of the personality function.  This also
occurs in a section which is loaded.

>From the debugging I did, the symbols appear to be symbols for
weak functions.

I have confirmed that the problem is somehow related to the generation
of dwarf2 eh information.

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