Re: PATCH: PR ld/3958: ELF linker failed to handle relocation against ABS section

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Feb 08, 2007 at 03:19:32AM +1030, Alan Modra wrote:
> On Sat, Feb 03, 2007 at 11:58:12AM -0800, H. J. Lu wrote:
> [snip]
> > 	* elflink.c (elf_link_input_bfd): Don't remove the symbol
> > 	reference from relocations against symbols from removed input
> > 	section.
> [snip]
> > --- binutils/bfd/elflink.c.abs	2007-02-03 09:11:04.000000000 -0800
> > +++ binutils/bfd/elflink.c	2007-02-03 11:52:45.000000000 -0800
> > @@ -7754,14 +7754,17 @@ elf_link_input_bfd (struct elf_final_lin
> >  			    }
> >  			}
> >  
> > -		      /* Remove the symbol reference from the reloc, but
> > -			 don't kill the reloc completely.  This is so that
> > -			 a zero value will be written into the section,
> > -			 which may have non-zero contents put there by the
> > -			 assembler.  Zero in things like an eh_frame fde
> > -			 pc_begin allows stack unwinders to recognize the
> > -			 fde as bogus.  */
> > -		      rel->r_info &= r_type_mask;
> > +		      /* We can't use relocation against STN_UNDEF to
> > +			 indicate that a relocation entry is against a
> > +			 symbol from a removed input section since it is
> > +			 used for relocation against constant.  See
> > +			 PR 3958.  We need to use elf_discarded_section
> > +			 to check if a zero value should be be written
> > +			 into the section, which may have non-zero
> > +			 contents put there by the assembler.  Zero
> > +			 in things like an eh_frame fde pc_begin
> > +			 allows stack unwinders to recognize the fde as
> > +			 bogus.  */
> >  		      rel->r_addend = 0;
> >  		    }
> 
> Have you checked how "ld -r" and "ld --emit-relocs" are affected by
> this change?  I suspect breakage..

Are there testcases for them?


H.J.