This is the mail archive of the
mailing list for the binutils project.
Re: ld segfault on incrementally linked object
- To: Ian Thompson <iant at palmchip dot com>
- Subject: Re: ld segfault on incrementally linked object
- From: amodra at one dot net dot au
- Date: Thu, 17 May 2001 21:51:53 +0930
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- References: <3B0047B3.AA574848@palmchip.com> <20010515123930.B11835@squeak.one.net.au> <3B00A89B.F84145@palmchip.com> <20010515132806.D11835@squeak.one.net.au> <3B00AC41.D86C177F@palmchip.com> <20010515140735.H11835@squeak.one.net.au> <3B02CBB1.429C2531@palmchip.com>
On Wed, May 16, 2001 at 11:49:21AM -0700, Ian Thompson wrote:
> Sorry to keep bothering you, but I also noticed that I am seeing similar
> problems with the debug info when looking at it with the newest GDB
> release. Would I be correct in assuming that it's unlikely for this to
> be a debugger problem?
Strictly speaking, it is a debugger problem, but it's one that the
linker may need to work around. Let's see if I can explain.
ELF object files have a number of sections, code (.text), data, rodata
etc., and each of these sections may have a corresponding relocation
section containing a number of relocation records. A relocation
record consists of four piece of information, its type, the symbol we
are relocating against, an addend to the symbol, and the offset within
the code/data section where the reloc applies. When an object file is
linked into an executable, both the section and it's relocation section
must be consulted to determine the final result. You might think
addends would only rarely be used, but gas on many targets translates
relocations against local syms to a relocation against the start of
the local symbol's section plus the appropriate addend. That way, you
don't need to keep huge numbers of local syms in a symbol table.
To complicate matters, there are two types of relocation, REL, where
the relocation addend is stored in the code/data section in the same
place as the reloc applies, and RELA, where the relocation addend is
stored in the relocation section. For RELA relocs, the linker can
(and does) ignore the data in the section where the relocation applies.
We use this fact when doing a "ld -r" on sections with RELA relocs,
and just update all the relocation addends that are against the start
of a section. We don't bother applying relocations to the section
data, as whatever is there is irrelevant. Or at least it would be
irrelevant if the world were an ideal place. Unfortunately, gdb and
other debuggers (and even binutils itself) read the raw data from
debug sections without applying the relocs.