This is the mail archive of the
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: Tue, 28 Jun 2016 13:58:53 -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> <CAAs8HmzH3qjeOSHYe_WEEdx-iuF5oGn5FwkA9vtUBV_5gO3r4w at mail dot gmail dot com> <CAJimCsEATs8PYb7FAJ43OcF07z5hjRApsAptYnvYajsn246a-A at mail dot gmail dot com> <CAAs8HmwnGgr5vVhEqGjZHEkhFYJbnUcvCWPkQj0y6zOi3ASJpQ at mail dot gmail dot com> <CAJimCsFnf5F4oj904Hvi39sqCkJ6Oqz2ZE9VsDRmk+Kcy7Gayg at mail dot gmail dot com>
On Tue, Jun 28, 2016 at 12:31 PM, Cary Coutant <email@example.com> wrote:
>> Yes, good point. I am a little confused about this new relocation
>> elfcpp::R_X86_64_GOTPCRELX. I have attached a patch that reverts to
>> the change you suggested where I check for conversion always.
>> However, is it safe to assume that a elfcpp::R_X86_64_GOTPCRELX
>> relocation implies that the instruction containing the relocation is
>> eligible for one of the conversions *always* ?
> Here's HJ's original proposal:
> It looks like that relocation marks several different instructions
> sequences that are eligible for transformation, so it looks like you
> may still have to look at the opcode. But it might be the case that in
> Scan::global(), all we need to know is that *some* transformation is
> going to happen that will remove the need for the GOT entry -- it
> doesn't really matter which one.
> HJ, can you clarify? If we have a GOTPCRELX relocation, what other
> conditions are sufficient to guarantee that one of the proposed
> translations will take place during relocation?
All GOTPCRELX relocations can be converted if symbol is resolved
locally without relocation overflow.