This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [ARM] PR ld/20608
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