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 03:48:18PM -0500, Daniel Jacobowitz wrote:
> > The relocation is the only way to associate the real address with the
> > debug info in the case of dynamic linker overrides.
> 
> I think this argument is bogus, related to the same problems we have
> with debug info for discarded sections: the debug information describes
> a particular copy of this symbol.

  extern int x __asm__("y");
  int foo()
  {
    return x*2;
  }

Now stop in "foo" and print x.

How are you going to find out that x has even been renamed.  Certainly
there's no debug info that describes this.  Suppose you invent something.
Now how are you going to know that we bound to symbol version y@LIB.1
as opposed to y@LIB.2?  Certainly that's not something the compiler has
any knowledge of; only the linker can know that.

I'll stick by my claim that the debugger is SOL without the reloc.

> If the runtime linker chooses a
> different copy of the symbol, we will get at best pot luck by using
> debug info for this copy.

(1) The debugger can't even begin to find the "real" copy of the symbol
    without the reloc.

(2) Whatever the type of the "real" copy of the symbol, the local debug
    info accurately describes how the variable is used and seen *here*.


r~


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