Re: [RFA] Relocate debug information in object files (e.g. add-symbol-file)

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 15, 2002 at 05:11:01PM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > This fixes a nasty problem debugging kernel modules on PowerPC.  The test is
>  > in my previous message to this list today; it fixes:
>  > FAIL: gdb.base/relocate.exp: static variables have different addresses
>  > 
>  > The problem goes like this: We know, when loading a new file at a specified
>  > offset, that addresses in debug info are going to be a bit off.  We shift
>  > them all by the appropriate constants (well, sometimes the appropriate
>  > constants.  PowerPC has other problems with .data vs .sdata occasionally).
>  > Shifting by constant section offsets is all we do.
>  > 
>  > On i386 and many other targets this suffices.  Why?  Because the debug info
>  > looks like this:
>  > 22     STSYM  0      1      00000000 934    static_foo:S(0,1)
>  > 23     STSYM  0      2      00000004 952    static_bar:S(0,1)
>  > 0000011c  00000301 R_386_32          00000000   .data
>  > 00000128  00000301 R_386_32          00000000   .data
>  > 
>  > On PowerPC, it doesn't look like that at all.  I believe the reason has to
>  > do with the ABI allowing .sdata optimizations.  It may also show up on other
>  > architectures that use RELA; even though the offset will still be against
>  > the section in that case, it will be shifted into the relocation entry
>  > instead of the debug info directly.  Instead we have:
>  > 22     STSYM  0      1      00000000 948    static_foo:S(0,1)
>  > 23     STSYM  0      2      00000000 966    static_bar:S(0,1)
>  >   0000011c  00601 R_PPC_ADDR32          00000000  static_foo	+ 0
>  >   00000128  00701 R_PPC_ADDR32          00000004  static_bar	+ 0
>  > 
>  > The important changes are: the +4 in static_bar's stab has disappeared, and
>  > the relocations are now against symbols.
>  > 
>  > The only way to make sense of this is to relocate the section.  It turned
>  > out to be easier than I feared.  BFD provides (almost) the perfect hooks; we
>  > need to fake a couple of data structures in order to pretend that we're a
>  > linker, but that's it.  One consequence is that (in the case of an object
>  > file only, not in the unchanged normal case) we preread the entire stabs
>  > debug section.  Since this will only happen for individual object files, and
>  > we don't keep it around, the memory increase doesn't worry me.  The
>  > relocation itself is blindingly fast (imperceptible on a module I have here
>  > with 4000 relocations and tons of symbols).
>  > 
>  > How does this patch look?  OK to commit?
>  > 
> 
> Sorry, I don't like it too much.
> 
> You are using PTR, I would prefer if you didn't. True/false were both
> eliminated from gdb.  Also, I don't really like the idea to introduce

Both easily fixed.  Sorry about missing the true/false thing; I
introduced not a single new use of PTR (just moved) but if you'd rather
I can eliminate them.  They were already present.

> the dummy functions.  Would it be possible to add something to bfd to
> provide a better interface that is not just taylored to the linker?
> For instance bfd has the file linker.c to provide such an
> interface. Could we have a debugger.c file? How about writing a
> simplified version of bfd_generic_get_relocated_section_contents so the
> need of the dummy parameters would be eliminated? In a sense you already
> have started that in symfile_relocate_debug_section.

Well, I can not redo it so that the dummy arguments are not necessary. 
This is a hook into a substantial portion of BFD, and e.g. the error
functions are assumed present.  I could theoretically provide them
internally in BFD and come up with a new entry point... but I can't
wrap my head around what it should look like.  I'll think about this.

> I also am not sure about the use of the global stabs_data. I know
> dbxread.c is not the best written file in gdb, but... Maybe you can
> have accessor functions? Don't know, stabs_seek ? Stabs_seek would
> decide whether to do a bfd_seek or a buffer pointer/counter adjustment.

I actually was going to redo this with stabs_seek this week.  Peter
Schauer pointed out that I can get better performance by relocating in
dbx_psymtab_to_symtab instead of read_ofile_symtab.


Thanks for the comments.  I won't have time to address them for a
little while, but I'll redo the patch with corrections when I do.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer