This is the mail archive of the
mailing list for the binutils project.
Re: [ARM] PR ld/20608
- From: Alan Modra <amodra at gmail dot com>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Christophe Lyon <christophe dot lyon at linaro dot org>, binutils at sourceware dot org
- Date: Fri, 23 Sep 2016 08:55:24 +0930
- Subject: Re: [ARM] PR ld/20608
- Authentication-results: sourceware.org; auth=none
- References: <CAKdteOafjnhgqshyDvk0Q5r_yT4cVgz11PrPi=ye5oOCNhQaHg@mail.gmail.com> <firstname.lastname@example.org> <email@example.com>
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.
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.
Australia Development Lab, IBM