[ARM] PR ld/20608

Christophe Lyon christophe.lyon@linaro.org
Mon Oct 10 08:22:00 GMT 2016


Tristian,

Ping for backport to 2.26 / 2.27 ?

Thanks,

Christophe


On 3 October 2016 at 09:06, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> Hi Tristan,
>
> Is it OK to backport this patch to 2.27 ? 2.26?
>
> Thanks,
>
> Christophe
>
>
> On 28 September 2016 at 01:57, Christophe Lyon
> <christophe.lyon@linaro.org> 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?
>>
>>> 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



More information about the Binutils mailing list