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]
Other format: [Raw text]

Re: linker relocation of debug information


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 <drow@mvista.com>
> > 
> > > 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 RELA
> > relocations.
> 
> 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:
  http://sources.redhat.com/ml/binutils/2001-10/msg00078.html

Alan's response:
  http://sources.redhat.com/ml/binutils/2001-10/msg00081.html

The rejection:
  http://sources.redhat.com/ml/binutils/2001-10/msg00130.html

Jakub's followup:
  http://sources.redhat.com/ml/binutils/2001-10/msg00131.html

  > This is similar to my sparc32 patch from July.
  > Basically, I don't think we should output .rela.* sections for debugging
  > sections in shared libraries (of course, unless --emit-relocs), gdb doesn't
  > 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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