linker relocation of debug information
Fri Jan 30 22:03:00 GMT 2004
I've fixed our inital issue. For now our 2.12.1 linkers will relocate
debug information as before. Thanks for all your helpful pointers.
PS. I changed mailers so if it's still doing strange things let me know.
Daniel Jacobowitz wrote:
> On Wed, Jan 28, 2004 at 05:55:15PM -0500, Daniel Jacobowitz wrote:
>>On Wed, Jan 28, 2004 at 02:31:49PM -0800, Geoff Keating wrote:
>>>>Date: Wed, 28 Jan 2004 15:48:18 -0500
>>>>From: Daniel Jacobowitz <firstname.lastname@example.org>
>>>>I don't remember what Geoff's objection was. Mind reminding me?
>>>I don't remember either (it's surely in the mail archives), but one
>>>objection is that some versions of the Sun linker add the address in
>>>the memory location to the computed symbol value, so the memory
>>>location needs to be zeroed for correct behaviour on systems with
>>I think we must be talking about different things - I'm talking about
>>not emitting relocations for this information, so the value in the
>>memory location would be the only one used.
>>I'll go check the archives.
> Here's the submission:
> Alan's response:
> The rejection:
> Jakub's followup:
> > This is similar to my sparc32 patch from July.
> > Basically, I don't think we should output .rela.* sections for
> > sections in shared libraries (of course, unless --emit-relocs), gdb
> > use it anyway and most other ELF backends don't emit them.
> I believe this is a known problem with GDB which will be corrected
> eventually. With stabs, it's not clear what the correct behaviour is,
> but with DWARF (which will be the default in GCC 3.1) it's clearly
> correct to generate and use the relocs.
> I have since implemented the GDB support in question. In practice, it
> is only _useful_ for loading ET_REL objects. For ET_DYN, all we ever
> get (just verified for DWARF-2, I think it's true for stabs also) is
> RELATIVE relocs. They add no information.
> I really don't think that emitting these relocations buys GDB anything.
> Richard points out that they contain symbol versioning information that
> the debug information does not. I think that's pretty marginal, but if
> y'all really think it matters, then we can continue to emit
> non-RELATIVE relocs.
> One advantage of dumping these relocations is that we don't have to
> process relocations when reading in the debug info - we can mmap
> .debug_info and be done, no slurping the symbol table, resolving
> references, et cetera.
More information about the Binutils