linker relocation of debug information

Daniel Jacobowitz
Wed Jan 28 21:29:00 GMT 2004

On Wed, Jan 28, 2004 at 01:18:27PM -0800, Richard Henderson wrote:
> 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.

I stick by my claim that the reloc doesn't help anything here.  Look at
what GCC produces now:

 <1><f2>: Abbrev Number: 4 (DW_TAG_variable)
     DW_AT_name        : x
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 1
     DW_AT_MIPS_linkage_name: *y
     DW_AT_type        : <eb>
     DW_AT_external    : 1
     DW_AT_declaration : 1

The best way I can think of to represent this is to just remove the *,
which is probably an artifact of GCC internals.  If we had the reloc,
it wouldn't help, because it would not convey any more or less
information than the DW_AT_MIPS_linkage_name above.  If there's any
ambiguity as to where "y" lives, then there will be the same ambiguity
in which symbol GDB should resolve the relocation against "y" to.  We
can't practically ask the dynamic linker to answer the question.

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

Anyway, you are talking about relocations against undefined external
symbols - a relocation that we don't even emit now, since we don't emit
a DW_AT_location corresponding to declarations of external variables. 
And I can't see why we ever should.  I am talking about all the useless
relocations that do get emitted, for instance, describing local
variables or function types.  Here are the relocations for your example
on PPC:

Relocation section '.rela.debug_info' at offset 0x298c contains 12 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000006  00000016 R_PPC_RELATIVE                               00000000
0000000c  00000016 R_PPC_RELATIVE                               00000000
00000099  00000016 R_PPC_RELATIVE                               00000056
0000009f  00000016 R_PPC_RELATIVE                               000000be
00000048  00000016 R_PPC_RELATIVE                               0000000e
0000004e  00000016 R_PPC_RELATIVE                               0000008e
00000052  00000016 R_PPC_RELATIVE                               0000196c
00000056  00000016 R_PPC_RELATIVE                               00001914
0000005e  00000016 R_PPC_RELATIVE                               00000022
00000062  00000016 R_PPC_RELATIVE                               00000000
00000073  00000016 R_PPC_RELATIVE                               00001918
00000077  00000016 R_PPC_RELATIVE                               0000196c

Those R_PPC_RELATIVE relocations convey absolutely nothing except a
pain, since they move the addends out of .debug_info.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

More information about the Binutils mailing list