Re: Next over function with Secure PLT

[Michael Eager <eager@eagerm.com>]

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