Re: [ARM] PR ld/20608

["Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>]

On 28/09/16 00:57, Christophe Lyon wrote:
> Hi,
> 
> Sorry for the delay, I've just committed the patch as approved by Nick.
> 
> Tristan, is it OK to backport this patch to 2.27 ? 2.26 ?
> 
> On 23 September 2016 at 01:25, Alan Modra <amodra@gmail.com> wrote:
>> On Thu, Sep 22, 2016 at 04:39:30PM +0100, Richard Earnshaw (lists) wrote:
>>> So this patch got me wondering.  If the PLT slot is so far away that we
>>> need an indirect jump to get there, why don't we clone the PLT code
>>> sequence at the veneer location?  As I recall there's nothing
>>> architectural about placing all the PLT slots together, it's just more
>>> convenient to do that.  We could even have the clone in Thumb-2 code if
>>> that's appropriate, so that it's compatible with tail calls.
>>
> 
> If there are multiple PLT slots for the same function,
> doesn't this break the uniqueness of a function pointer?
> 

Yes, you have to ensure that only one plt stub is used for function
pointers (this is true globally for the program, so each shared library
with a PLT for a function f() has to be able to sort this out), but
that's a relatively small issue that's well within the linkers control.
Duplicate stubs would be entirely private and can't leak into function
pointer addresses.

R.


>> Yeah, that's what ppc64 does.  It does have one downside in that
>> synthetic plt symbols are not so easy to add.
>>
>>           /* FIXME: It would be very much nicer to put sym@plt on the
>>              stub rather than on the glink branch table entry.  The
>>              objdump disassembler would then use a sensible symbol
>>              name on plt calls.  The difficulty in doing so is
>>              a) finding the stubs, and,
>>              b) matching stubs against plt entries, and,
>>              c) there can be multiple stubs for a given plt entry.
>>
>>              Solving (a) could be done by code scanning, but older
>>              ppc64 binaries used different stubs to current code.
>>              (b) is the tricky one since you need to known the toc
>>              pointer for at least one function that uses a pic stub to
>>              be able to calculate the plt address referenced.
>>              (c) means gdb would need to set multiple breakpoints (or
>>              find the glink branch itself) when setting breakpoints
>>              for pending shared library loads.  */
>>
>> We avoid the problem by enabling --emit-stub-syms by default.
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>