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
next prev 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