This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: PR ld/3958: ELF linker failed to handle relocation against STN_UNDEF
- From: Daniel Jacobowitz <drow at false dot org>
- To: "H. J. Lu" <hjl at lucon dot org>, binutils at sourceware dot org
- Date: Mon, 5 Mar 2007 19:28:49 -0500
- Subject: Re: PATCH: PR ld/3958: ELF linker failed to handle relocation against STN_UNDEF
- References: <877iu4k03j.fsf@firetop.home> <20070227014036.GA9676@caradoc.them.org> <87mz309c9k.fsf@firetop.home> <20070227121051.GA5903@caradoc.them.org> <20070227230314.GL29005@bubble.grove.modra.org> <20070228012241.GB11623@lucon.org> <20070228013530.GN29005@bubble.grove.modra.org> <20070303032002.GA13632@lucon.org> <20070303230422.GA1996@lucon.org> <20070305235239.GA29691@bubble.grove.modra.org>
On Tue, Mar 06, 2007 at 10:22:39AM +1030, Alan Modra wrote:
> On Sat, Mar 03, 2007 at 03:04:22PM -0800, H. J. Lu wrote:
> > But we shouldn't use STN_UNDEF to indicate relocations
> > against symbols from removed input sections since STN_UNDEF simply
> > means 0 as the symbol value for relocation.
>
> Agreed. We should instead either relocate against the corresponding
> symbol from the kept section and emit a reloc against that symbol, or
> zero the section contents and emit an R_*_NONE reloc. The difficulty
> is that this means touching all the ELF backend relocate_section
> functions, because we need the reloc howto function to know which bits
> need zeroing. Also, the section contents will need to be cleared on
> a relocatable link.
This should happen in more or less the same places my previous broken
patch touched all the backends, though - shouldn't it?
--
Daniel Jacobowitz
CodeSourcery