This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH][x86_64] Convert indirect call via GOT to direct when possible
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: Sriraman Tallam <tmsriram at google dot com>, binutils <binutils at sourceware dot org>, David Li <davidxl at google dot com>
- Date: Fri, 10 Jun 2016 13:33:52 -0700
- Subject: Re: [PATCH][x86_64] Convert indirect call via GOT to direct when possible
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmxxdBpS7w8udZgK0QFi5TnenU3wGhpPfhWeKE8Tr=thvA at mail dot gmail dot com> <CAMe9rOpk3aOK5mMkKvYQyzeQxJ-h8o+3KjLRikKSkLmMfqoUtg at mail dot gmail dot com> <CAAs8Hmw2KQ2neDNP5cnQPBVBZMJthvQGTARPiwa-NfAx5R6ugw at mail dot gmail dot com> <CAMe9rOrOyYv0+svcObyaBcoYbAWZTadEPm-mAGQUFFyNjPgctg at mail dot gmail dot com> <CAAs8HmzoxWe2YpvjviV-bs2BRotGa_WFWbCyyLh-_L=s00yxjQ at mail dot gmail dot com> <CAJimCsF4h+e_Ey-fGxPXM0h8ZJ-SmSzyP9XoYaNuEOByJSm=1A at mail dot gmail dot com>
On Fri, Jun 10, 2016 at 1:06 PM, Cary Coutant <ccoutant@gmail.com> wrote:
> template<class View_type>
> static inline bool
> can_convert_callq_to_direct(const Symbol* gsym, unsigned int r_type,
> size_t r_offset, View_type* view)
> {
> gold_assert(gsym != NULL);
> // We cannot do the conversion unless it's a GOTPCRELX relocation.
> if (r_type != elfcpp::R_X86_64_GOTPCRELX)
> return false;
> // We cannot convert references to IFUNC symbols, or to symbols that
> // are not local to the current module.
> if (gsym->type() == elfcpp::STT_GNU_IFUNC
> || gsym->is_undefined ()
> || gsym->is_from_dynobj()
> || gsym->is_preemptible())
> return false;
> // Check for a CALLQ or JMPQ opcode.
> return ((*view)[r_offset - 2] == 0xff
> && ((*view)[r_offset - 1] == 0x15
> || (*view)[r_offset - 1] == 0x25));
> }
>
> A couple of observations, though:
>
> 1. Sri, in your patch, you just test for sym type == STT_FUNC. Isn't
> it sufficient to test for sym type != STT_GNU_IFUNC (as in the
> convert-to-lea case)? I don't think it really matters -- if we see a
> jump to an STT_OBJECT or STT_NOTYPE symbol, why isn't the
> transformation just as valid?
>
> 2. HJ, given an R_X86_64_GOTPCRELX relocation, is it still necessary
> to check the opcode during Scan::global()? Doesn't the relocation
> guarantee that it's an appropriate instruction for the transformation?
> I think in both cases, we could skip fetching the section contents if
> we have this relocation.
Doesn't gold make different decision based on opcode, like
branch vs non-branch?
--
H.J.