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: [PATCH][x86_64] Convert indirect call via GOT to direct when possible


> 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:

   https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0

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?

> If this is true, then I could completely remove
> can_convert_callq_to_direct  and simplify the code a lot more.
> Otherwise, the check is needed in both places.   Will
> -relax-relocations=yes in the assembler do the checks before
> converting R_X86_64_GOTPCREL to  now R_X86_64_GOTPCRELX. The attached
> patch now contains a conservative check in both places to
> can_convert_callq_to_direct.

There are other conditions in the can_convert* routines; I don't think
you can completely remove the routine.

Your latest version of the patch looks good; please go ahead and apply
it. I think for now it's safest to check the opcodes, and we can
discuss further improvements as a follow-up.

Thanks!

-cary


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