This is the mail archive of the 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]
Other format: [Raw text]

Re: linker relocation of debug information

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 <>

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.

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