This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ld segfault on incrementally linked object


> From: amodra@one.net.au
> Date: Sat, 12 May 2001 23:22:46 +0930

> elf32-ppc.c:ppc_elf_relocate_section (and other rela targets) say this
> about incremental/relocatable linking:
> 
> 	  /* This is a relocateable link.  We don't have to change
> 	     anything, unless the reloc is against a section symbol,
> 	     in which case we have to adjust according to where the
> 	     section symbol winds up in the output section.  */
> 
> That's mostly right too, as the section data with the reloc will be
> replaced during final link.  What we have in the section doesn't
> matter too much.  However, dwarf1.c:_bfd_dwarf1_find_nearest_line,
> which is called when the linker hits an undefined symbol, reads the
> _unrelocated_ .debug data to determine which line of code referenced
> the symbol.  In particular, the low_pc and high_pc bounds on line
> debug info are read, and need to be relocated before they can be used
> correctly.
> 
> Sooo, either the above quoted comment is wrong and we do need to
> perform section relocations for incremental linking, or dwarf1.c
> needs to relocate debug info.  I don't particularly like the second
> option for a number of reasons.

The second option is the correct one.  If there's a reloc, and we are
using RELA relocs, the data at the reloc can be anything.

Even if we changed this for GNU ld, it would just make it incompatible
with other vendors' ways of generating ELF .o files.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]