Next over function with Secure PLT

Next over function with Secure PLT

[Michael Eager]

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

Re: Next over function with Secure PLT

[Ryan Arnold]

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

Re: Next over function with Secure PLT

[Alan Modra]

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

Re: Next over function with Secure PLT

[Michael Eager]

On 12/07/2011 08:01 PM, Alan Modra wrote:
> 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.

Or I might have to backport the binutils patch.  Another work-
around is to force --emit-stub-sims.

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

OK.  That was the detail I was missing.

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

I wanted to avoid pattern matching code because of the dependency it
creates between code generation and debugging.  But that shouldn't
be much of an issue or hard to implement.

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

Re: Next over function with Secure PLT

[Mark Kettenis]

> Date: Wed, 07 Dec 2011 23:45:19 -0800
> From: Michael Eager <eager@eagerm.com>
> 
> > gdb ought to just pattern match the stub code to recognize when the pc
> > is in a stub.
> 
> I wanted to avoid pattern matching code because of the dependency it
> creates between code generation and debugging.  But that shouldn't
> be much of an issue or hard to implement.

This tends to be less of an issue with PLT stubs since their
instruction sequence is in many cases prescribed by the ABI.