This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Next over function with Secure PLT
- From: Ryan Arnold <rsa at us dot ibm dot com>
- To: Michael Eager <eager at eagerm dot com>
- Cc: gdb at sourceware dot org, Alan Modra <amodra at bigpond dot net dot au>, amodra at gmail dot com
- Date: Wed, 07 Dec 2011 21:43:16 -0600
- Subject: Re: Next over function with Secure PLT
- References: <4EE0088C.4070208@eagerm.com>
- Reply-to: rsa at us dot ibm dot com
On Wed, 2011-12-07 at 16:45 -0800, Michael Eager wrote:
> 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?
I'm replying to CC Alan on his new-ish email account.
Ryan S. Arnold