Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Eager <eager@eagerm.com>
To: gdb@sourceware.org
Cc: Alan Modra <amodra@bigpond.net.au>, "Ryan S.Arnold" <rsa@us.ibm.com>
Subject: Next over function with Secure PLT
Date: Thu, 08 Dec 2011 00:45:00 -0000	[thread overview]
Message-ID: <4EE0088C.4070208@eagerm.com> (raw)

Hi --

When using PowerPC Secure PLT, trying to "next" over a
library function in a shared library does not work correctly.
Instead of skipping over the function, gdb steps through
the PLT entry which shows up as code in
call___do_global_ctors_aux.

This doesn't happen when "nexting" over a library function
in the executable.  Next works the same as with a local function.

When reading the executable, ppc_elf_get_synthetic_symtab()
calls is_nonpic_glink_stub() to recognizes the PLT stub and
then generates internal symbols for each PLT stub like foo@plt.
It also creates an entry for __glink and __glink_PLTresolve.

If I modify is_nonpic_glink_stub() to recognize the shared
library PLT stub format, similar internal symbols are created
and gdb seems to work correctly.

There's a comment before the call:
  /* If the stubs are those for -shared/-pie then we might have
      multiple stubs for each plt entry.  If that is the case then
      there is no way to associate stubs with their plt entries short
      of figuring out the GOT pointer value used in the stub.  */
   if (!is_nonpic_glink_stub (abfd, glink,
			     glink_vma - GLINK_ENTRY_SIZE - glink->vma))

What is this trying to tell me?  What are the circumstances where
there would be multiple stubs for each PLT entry?  If there are
multiple stubs, then this might create multiple foo@plt symbols
with different values.  Would this cause any problems?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


             reply	other threads:[~2011-12-08  0:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-08  0:45 Michael Eager [this message]
2011-12-08  3:44 ` Ryan Arnold
2011-12-08  4:01 ` Alan Modra
2011-12-08  7:45   ` Michael Eager
2011-12-08  8:53     ` Mark Kettenis

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=4EE0088C.4070208@eagerm.com \
    --to=eager@eagerm.com \
    --cc=amodra@bigpond.net.au \
    --cc=gdb@sourceware.org \
    --cc=rsa@us.ibm.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