linker relocation of debug information
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_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
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.
MontaVista Software Debian GNU/Linux Developer
More information about the Binutils