Adding ia32/x86-64 psABI.
On Wed, May 27, 2015 at 5:44 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Wed, May 27, 2015 at 1:03 PM, Richard Henderson <r...@redhat.com> wrote:
>> There's one problem with the couple of patches that I've seen go by wrt
>> eliding
>> PLTs with -z now, and relaxing inlined PLTs (aka -fno-plt):
>>
>> They're currently using the same relocations used by data, and thus the
>> linker
>> and dynamic linker must ensure that pointer equality is maintained. Which
>> results in branch-to-branch-(to-branch) situations.
>>
>> E.g. the attached test case, in which main has a plt entry for function A in
>> a.so, and the function B in b.so calls A.
>>
>> $ LD_BIND_NOW=1 gdb main
>> ...
>> (gdb) b b
>> Breakpoint 1 at 0x400540
>> (gdb) run
>> Starting program: /home/rth/x/main
>> Breakpoint 1, b () at b.c:2
>> 2 void b(void) { a(); }
>> (gdb) si
>> 2 void b(void) { a(); }
>> => 0x7ffff7bf75f4 <b+4>: callq 0x7ffff7bf74e0
>> (gdb)
>> 0x00007ffff7bf74e0 in ?? () from ./b.so
>> => 0x7ffff7bf74e0: jmpq *0x20034a(%rip) # 0x7ffff7df7830
>> (gdb)
>> 0x0000000000400560 in a@plt ()
>> => 0x400560 <a@plt>: jmpq *0x20057a(%rip) # 0x600ae0
>> (gdb)
>> a () at a.c:2
>> 2 void a() { printf("Hello, World!\n"); }
>> => 0x7ffff7df95f0 <a>: sub $0x8,%rsp
>>
>>
>> If we use -fno-plt, we eliminate the first callq, but do still have two
>> consecutive jmpq's.
You get consecutive jmpq's because x86 PLT entry is used as the
canonical function address. If you compile main with -fno-plt -fPIE, you
get:
(gdb) b b
Breakpoint 1 at 0x7ffff7bf75f0: file b.c, line 4.
(gdb) r
Starting program: /export/home/hjl/bugs/binutils/pr18458/main
Breakpoint 1, b () at b.c:4
4 {
(gdb) si
5 a();
(gdb)
a () at a.c:4
4 {
(gdb)
>> If seems to me that we ought to have different relocations when we're only
>> going to use a pointer for branching, and when we need a pointer to be
>> canonicalized for pointer comparisons.
>>
>> In the linked image, we already have these: R_X86_64_GLOB_DAT vs
>> R_X86_64_JUMP_SLOT. Namely, GLOB_DAT implies "data" (and therefore pointer
>> equality), while JUMP_SLOT implies "code" (and therefore we can resolve past
>> plt stubs in the main executable).
>>
>> Which means that HJ's patch of May 16 (git hash 25070364), is less than
>> ideal.
>> I do like the smaller PLT entries, but I don't like the fact that it now
>> emits
>> GLOB_DAT for the relocations instead of JUMP_SLOT.
>
> ld.so just does whatever is arranged by ld. I am not sure change ld.so
> is a good idea. I don't what kind of optimization we can do when function
> is called and its address it taken.
>
>>
>> In the relocatable image, when we're talking about -fno-plt, we should think
>> about what relocation we'd like to emit. Yes, the existing R_X86_64_GOTPCREL
>> works with existing toolchains, and there's something to be said for that.
>> However, if we're talking about adding a new relocation for relaxing an
>> indirect call via GOTPCREL, then:
>>
>> If we want -fno-plt to be able to hoist function addresses, then we're going
>> to
>> want the address that we load for the call to also not be subject to possible
>> jump-to-jump.
>>
>> Unless we want the linker to do an unreasonable amount of x86 code
>> examination
>> in order to determine mov vs call for relaxation, we need two different
>> relocations (preferably using the same assembler mnemonic, and thus the
>> correct
>> relocation is enforced by the assembler).
>>
>> On the users/hjl/relax branch (and posted on list somewhere), the new
>> relocation is called R_X86_64_RELAX_GOTPCREL. I'm not keen on that "relax"
>> name, despite that being exactly what it's for.
>>
>> I suggest R_X86_64_GOTPLTPCREL_{CALL,LOAD} for the two relocation names.
>> That
>> is, the address is in the .got.plt section, it's a pc-relative relocation,
>> and
>> it's being used by a call or load (mov) insn.
>
> Since it is used for indirect call, how about R_X86_64_INBR_GOTPCREL?
>
> I updated users/hjl/relax branch to covert relocation in *foo@GOTPCREL(%rip)
> from R_X86_64_GOTPCREL to R_X86_64_RELAX_GOTPCREL so that
> existing assembly code works automatically with a new binutils.
>
>> With those two, we can fairly easily relax call/jmp to direct branches, and
>> mov
>> to lea. Yes, LTO can perform the same optimization, but I'll also agree that
>> there are many projects for which LTO is both overkill and unworkable.
>>
>> This does leave open other optimization questions, mostly around weak
>> functions. Consider constructs like
>>
>> if (foo) foo();
>>
>> Do we, within the compiler, try to CSE GOTPCREL and GOTPLTPCREL, accepting
>> the
>> possibility (not certainty) of jump-to-jump but definitely avoiding a
>> separate
>> load insn and the latency implied by that?
>>
>>
>> Comments?
Here is the new proposal to add R_X86_64_INDBR_GOTPCREL and
R_386_INDBR_GOT32. Comparing against the last proposal, I used
_INDBR_, instead of _RELAX_, and also I used the same assembler
mnemonic. Since only indirect branch instructions take a single
JumpAbsolute operand, it is quite easy to generate INDBR relocation
for indirect branches.
H.J.
-----
To avoid indirect branch to internal functions, I am proposing to add a
new relocation, R_X86_64_INDBR_GOTPCREL, to x86-64 psABI:
1. When branching to an external function, foo, toolchain generates
call/jmp *foo@GOTPCREL(%rip)
with R_X86_64_INDBR_GOTPCREL relocation, instead of
call/jmp foo[@PLT]
2. When function foo is locally defined, linker converts
call/jmp *foo@GOTPCREL(%rip)
to
nop call/jmp foo
3. Otherwise, linker treats R_X86_64_INDBR_GOTPCREL the same way as
R_X86_64_GOTPCREL.
For i386 psABI, we add R_386_INDBR_GOT32:
1. When branching to an external function, foo, in non-PIC mode,
toolchain generates
call/jmp *foo@GOT
with R_386_INDBR_GOT32 relocation, instead of
call/jmp foo
and in PIC mode
call/jmp *foo@GOT(%reg)
with R_386_INDBR_GOT32 relocation and REG holds the address
of GOT, instead of
call/jmp foo@PLT
2. When function foo is locally defined, linker converts
call/jmp *foo@GOT[(%reg)]
to
nop call/jmp foo
3. Otherwise,
a. In PIC mode, linker treats R_386_INDBR_GOT32 the same way as
R_386_GOT32 and "call/jmp *foo@GOT" is unsupported.
b. In no-PIC mode, linker computes its relocation value as relocation
value of R_386_GOT32 plus the address of GOT and converts
call/jmp *foo@GOT(%reg)
to
call/jmp *foo@GOT
if needed.
This new relocation effectively turns off lazy binding on function, foo.
For i386, compiler is free to choose any register to hold the address of
GOT and there is no need to make EBX a fixed register when branching to
an external function in PIC mode.
With this new relocation, only a one-byte NOP prefix overhead is added
when function, foo, which compiler determines is external, turns out to
be local at link-time, because of -Bsymbolic or a definition in another
input object file which compiler has no knowledge of.
The new -fno-plt GCC option can use R_X86_64_INDBR_GOTPCREL and
R_386_INDBR_GOT32 relocations if linker supports them to avoid indirect
branch to internal functions.
For x86-64 GCC, it is implemented in assembler and linker. Assembler should
generate R_X86_64_INDBR_GOTPCREL relocation, instead of
R_X86_64_GOTPCREL relocation for “call/jmp *foo@GOTPCREL(%rip)”
For i386 GCC, most is implemented in assembler and linker. Assembler should
generate R_386_INDBR_GOT32 relocation, instead of R_386_GOT32 relocation,
for “call/jmp *foo@GOT(%reg)”. GCC also needs to modify to generate
“call/jmp *foo@GOT” in non-PIC mode.
