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: Alan Modra <amodra at bigpond dot net dot au>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: binutils at sourceware dot org
- Date: Tue, 6 Mar 2007 10:22:39 +1030
- 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>
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.
I suppose I should look at doing this, since it was my idea to use a
reloc against STN_UNDEF as a means of passing the info through ld -r.
--
Alan Modra
IBM OzLabs - Linux Technology Centre