This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM] PR ld/20608


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.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]