This is the mail archive of the
mailing list for the binutils project.
Re: [ARM] PR ld/20608
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Tristan Gingold <gingold at adacore dot com>, binutils <binutils at sourceware dot org>
- Date: Mon, 10 Oct 2016 10:22:39 +0200
- Subject: Re: [ARM] PR ld/20608
- Authentication-results: sourceware.org; auth=none
- References: <CAKdteOafjnhgqshyDvk0Q5r_yT4cVgz11PrPi=ye5oOCNhQaHg@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <20160922232524.GB26008@bubble.grove.modra.org> <CAKdteObnYPXHi+fKMF3p0KNfRSM8LOOjG_yGpYBAqH_7_eiUZQ@mail.gmail.com> <CAKdteObthph3EhARufxc4+SKs6nfb=miK1CXHTC1LRvAAFz5nA@mail.gmail.com>
Ping for backport to 2.26 / 2.27 ?
On 3 October 2016 at 09:06, Christophe Lyon <email@example.com> wrote:
> Hi Tristan,
> Is it OK to backport this patch to 2.27 ? 2.26?
> On 28 September 2016 at 01:57, Christophe Lyon
> <firstname.lastname@example.org> wrote:
>> 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 <email@example.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