fake symbols to aid debugging

fake symbols to aid debugging

[Alan Modra]

PowerPC64 (and other architechures) use linker stubs for various things,
most notably to make calls to functions in shared objects.  Typical
disassembly looks like:

the stub
  7ea138:       3d 82 00 01     addis   r12,r2,1
  7ea13c:       f8 41 00 28     std     r2,40(r1)
  7ea140:       e9 6c 11 88     ld      r11,4488(r12)
  7ea144:       e8 4c 11 90     ld      r2,4496(r12)
  7ea148:       7d 69 03 a6     mtctr   r11
  7ea14c:       e9 6c 11 98     ld      r11,4504(r12)
  7ea150:       4e 80 04 20     bctr

call to stub
  87d6f0:       e8 7e 80 90     ld      r3,-32624(r30)
  87d6f4:       4b f6 ca 45     bl      7ea138 <._init+0xe9b8>
  87d6f8:       e8 41 00 28     ld      r2,40(r1)

Note the meaningless symbol given as target for the "bl".  Now, if you
know enough about the ABI, it's possible to figure out which function is
being called, but that's a pain.  In the case of PowerPC64 you need to
a) Find the value of r2 by looking at the calling function's opd entry.
   (with multiple GOT/TOC r2 is not fixed).
b) Perform the calculation done by the stub to find the plt entry
   address. 
c) Search the relocs to find the one for this particular plt entry.
   The symbol on the reloc gives the function name.

I waste enough time doing this that I figure it's worth doing something
about it.  My first idea, already implemented, was to have the linker
emit extra symbols to identify the stubs.  This works well but bloats
the symbol table and isn't on by default.  A better idea would be to
create the stub symbols on the fly.  With that in mind, I propose to
add two new bfd functions

long bfd_get_fake_symtab_upper_bound (bfd *abfd);
long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf);

analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab.

Comments?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: fake symbols to aid debugging

[Daniel Jacobowitz]

On Tue, Jul 29, 2003 at 12:02:58PM +0930, Alan Modra wrote:
> PowerPC64 (and other architechures) use linker stubs for various things,
> most notably to make calls to functions in shared objects.  Typical
> disassembly looks like:
> 
> the stub
>   7ea138:       3d 82 00 01     addis   r12,r2,1
>   7ea13c:       f8 41 00 28     std     r2,40(r1)
>   7ea140:       e9 6c 11 88     ld      r11,4488(r12)
>   7ea144:       e8 4c 11 90     ld      r2,4496(r12)
>   7ea148:       7d 69 03 a6     mtctr   r11
>   7ea14c:       e9 6c 11 98     ld      r11,4504(r12)
>   7ea150:       4e 80 04 20     bctr
> 
> call to stub
>   87d6f0:       e8 7e 80 90     ld      r3,-32624(r30)
>   87d6f4:       4b f6 ca 45     bl      7ea138 <._init+0xe9b8>
>   87d6f8:       e8 41 00 28     ld      r2,40(r1)
> 
> Note the meaningless symbol given as target for the "bl".  Now, if you
> know enough about the ABI, it's possible to figure out which function is
> being called, but that's a pain.  In the case of PowerPC64 you need to
> a) Find the value of r2 by looking at the calling function's opd entry.
>    (with multiple GOT/TOC r2 is not fixed).
> b) Perform the calculation done by the stub to find the plt entry
>    address. 
> c) Search the relocs to find the one for this particular plt entry.
>    The symbol on the reloc gives the function name.
> 
> I waste enough time doing this that I figure it's worth doing something
> about it.  My first idea, already implemented, was to have the linker
> emit extra symbols to identify the stubs.  This works well but bloats
> the symbol table and isn't on by default.  A better idea would be to
> create the stub symbols on the fly.  With that in mind, I propose to
> add two new bfd functions
> 
> long bfd_get_fake_symtab_upper_bound (bfd *abfd);
> long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf);
> 
> analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab.
> 
> Comments?

I may regret suggesting this... outgrowth of a similar conversation
with Jim a month or so ago.  Would it be feasible for the linker to
generate a DWARF compilation unit for these stubs, and fill it with
DW_AT_trampoline markers?  One of the forms of DW_AT_trampoline is just
a string which gives the function name, which is all you'd want from
what you said above.

As link-time DWARF generation goes this is a pretty simple one; you'd
only need one form.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: fake symbols to aid debugging

[Alan Modra]

On Mon, Jul 28, 2003 at 11:11:07PM -0400, Daniel Jacobowitz wrote:
> Would it be feasible for the linker to
> generate a DWARF compilation unit for these stubs, and fill it with
> DW_AT_trampoline markers?

Yes, I could do that.  Doesn't solve my disassembly problem though,
does it?  Even if gdb is clever enough to rummage through dwarf info
for calls via stubs, I'd like to have objdump -d print useful symbols.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: fake symbols to aid debugging

[Nick Clifton]

Hi Alan,

> I waste enough time doing this that I figure it's worth doing something
> about it.  My first idea, already implemented, was to have the linker
> emit extra symbols to identify the stubs.  This works well but bloats
> the symbol table and isn't on by default.  A better idea would be to
> create the stub symbols on the fly.  With that in mind, I propose to
> add two new bfd functions
>
> long bfd_get_fake_symtab_upper_bound (bfd *abfd);
> long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf);
>
> analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab.
>
> Comments?

Well a few questions actually:

Where would these fake symbols be held ?  In a new .fakesymtab
section?  Or are they entirely ephemeral and never stored in the
executable ?

Can the fake symbols be generated after the stubs are created ?  ie
can they be created for already existing libraries/executables ?

Would gdb users be able to set breakpoints on these fake symbols ?

Cheers
        Nick
        

Re: fake symbols to aid debugging

[Alan Modra]

On Tue, Jul 29, 2003 at 07:45:30AM +0100, Nick Clifton wrote:
> Hi Alan,
> 
> > I waste enough time doing this that I figure it's worth doing something
> > about it.  My first idea, already implemented, was to have the linker
> > emit extra symbols to identify the stubs.  This works well but bloats
> > the symbol table and isn't on by default.  A better idea would be to
> > create the stub symbols on the fly.  With that in mind, I propose to
> > add two new bfd functions
> >
> > long bfd_get_fake_symtab_upper_bound (bfd *abfd);
> > long bfd_canonicalize_fake_symtab (bfd *abfd, asymbol **buf);
> >
> > analogous to bfd_get_symtab_upper_bound and bfd_canonicalize_symtab.
> >
> > Comments?
> 
> Well a few questions actually:
> 
> Where would these fake symbols be held ?  In a new .fakesymtab
> section?  Or are they entirely ephemeral and never stored in the
> executable ?

They're ephemeral, but I discovered I needed to save some info away in
order to locate stubs.  For that reason, I think the idea of emitting
DWARF2 info for stubs is better.  Helps gdb out in tracing over stubs
too.

> Can the fake symbols be generated after the stubs are created ?  ie
> can they be created for already existing libraries/executables ?

That was my aim, but short of scanning all code it's hard to locate
stubs..

> Would gdb users be able to set breakpoints on these fake symbols ?

I think so.  It's a while since I poked around in gbd though..

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: fake symbols to aid debugging

[Daniel Jacobowitz]

On Tue, Jul 29, 2003 at 01:04:51PM +0930, Alan Modra wrote:
> On Mon, Jul 28, 2003 at 11:11:07PM -0400, Daniel Jacobowitz wrote:
> > Would it be feasible for the linker to
> > generate a DWARF compilation unit for these stubs, and fill it with
> > DW_AT_trampoline markers?
> 
> Yes, I could do that.  Doesn't solve my disassembly problem though,
> does it?  Even if gdb is clever enough to rummage through dwarf info
> for calls via stubs, I'd like to have objdump -d print useful symbols.

Well, yes and no.

Right now GDB only uses the minimal (ELF) symbol table when printing
symbols in disassembly.  We'd need to make it use the debug info.  I
think that's reasonable.  Making objdump do the same thing would
probably not be hard.  It wouldn't need a full reader, just one which
scanned top-level entities looking for subprograms and could parse
DW_AT_ranges or DW_AT_high/low_pc

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer