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

On Wed, Dec 07, 2011 at 04:58:22PM -0800, Michael Eager wrote:
> 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.

As an aside, if you use a newer linker symbols will be emitted on
each plt stub by default for -shared.

> 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.

Don't do that.  You can't easily know which plt entry is loaded by a
PIC stub.

> 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?

There can be multiple stubs using the same PLT entry when linking
-fPIC code.  -fPIC effectively gives you a 64k GOT per file, with
the result that r30 may differ from one function to another in the
executable.  Since r30 is used in a PIC stub to calculate the PLT
entry address, you need a different stub for different values of r30.

gdb ought to just pattern match the stub code to recognize when the pc
is in a stub.

-- 
Alan Modra
Australia Development Lab, IBM


  parent reply	other threads:[~2011-12-08  4:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-08  0:45 Michael Eager
2011-12-08  3:44 ` Ryan Arnold
2011-12-08  4:01 ` Alan Modra [this message]
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=20111208040118.GB10960@bubble.grove.modra.org \
    --to=amodra@gmail.com \
    --cc=eager@eagerm.com \
    --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