public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: binutils@sources.redhat.com
Cc: gdb@sources.redhat.com
Subject: fake symbols to aid debugging
Date: Tue, 29 Jul 2003 02:33:00 -0000	[thread overview]
Message-ID: <20030729023258.GH27145@bubble.sa.bigpond.net.au> (raw)

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

             reply	other threads:[~2003-07-29  2:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-29  2:33 Alan Modra [this message]
2003-07-29  3:11 ` Daniel Jacobowitz
2003-07-29  3:34   ` Alan Modra
2003-07-29 12:48     ` Daniel Jacobowitz
2003-07-29  6:50 ` Nick Clifton
2003-07-29  8:11   ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030729023258.GH27145@bubble.sa.bigpond.net.au \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).