Why are imported functions called so indirectly in Linux? - linux

Question

Consider a simple C program:
#include <stdio.h>
int main()
{
puts("Hello");
return 0;
}
Running it with GDB, having set LD_BIND_NOW=1 for simplicity, I can observe the following:
$ gdb -q ./test -ex 'b main' -ex r
Reading symbols from ./test...done.
Breakpoint 1 at 0x8048420
Starting program: /tmp/test
Breakpoint 1, 0x08048420 in main ()
(gdb) disas
Dump of assembler code for function main:
0x0804841d <+0>: push ebp
0x0804841e <+1>: mov ebp,esp
=> 0x08048420 <+3>: and esp,0xfffffff0
0x08048423 <+6>: sub esp,0x10
0x08048426 <+9>: mov DWORD PTR [esp],0x8048500
0x0804842d <+16>: call 0x80482c0 <puts#plt>
0x08048432 <+21>: mov eax,0x0
0x08048437 <+26>: leave
0x08048438 <+27>: ret
End of assembler dump.
(gdb) si 4
0x080482c0 in puts#plt ()
(gdb) disas
Dump of assembler code for function puts#plt:
=> 0x080482c0 <+0>: jmp DWORD PTR ds:0x8049670
0x080482c6 <+6>: push 0x0
0x080482cb <+11>: jmp 0x80482b0
End of assembler dump.
(gdb) si
_IO_puts (str=0x8048500 "Hello") at ioputs.c:35
35 {
(gdb)
Apparently, after binding the PLT entry to the function, we still do a two-step call:
call puts#plt
jmp [ds:puts_address]
Comparing this with how it's implemented in Win32, there all calls of imported functions, e.g. MessageBoxA, are done like
call [ds:MessageBoxA_address]
i.e. in a single step.
Even if taking lazy binding into account, it's still possible to have e.g. [puts_address] contain the call to _dl_runtime_resolve or whatever is needed on startup, so the one-step indirect call would still work.
So what's the reason for such a complication? Is this some sort of branch prediction or branch target prediction optimization?
EDIT in response to Employed Russian's answer (v2)
What I actually mean is that this indirection of call PLT; jump [GOT] is redundant even in the context of lazy binding. Consider the following example (relies on compilation without optimizations by gcc):
#include <stdio.h>
int main()
{
for(int i=0;i<3;++i)
{
puts("Hello");
__asm__ __volatile__("nop");
}
return 0;
}
Running it (with LD_BIND_NOW unset) in GDB:
$ gdb ./test -ex 'b main' -ex r -ex disas/r
Reading symbols from ./test...done.
Breakpoint 1 at 0x8048387
Starting program: /tmp/test
Breakpoint 1, 0x08048387 in main ()
Dump of assembler code for function main:
...
0x08048397 <+19>: c7 04 24 80 84 04 08 mov DWORD PTR [esp],0x8048480
0x0804839e <+26>: e8 11 ff ff ff call 0x80482b4 <puts#plt>
0x080483a3 <+31>: 90 nop
0x080483a4 <+32>: 83 44 24 1c 01 add DWORD PTR [esp+0x1c],0x1
...
Disassembling puts#plt, we can see the address of GOT entry for puts:
(gdb) disas 'puts#plt'
Dump of assembler code for function puts#plt:
0x080482b4 <+0>: jmp DWORD PTR ds:0x8049580
0x080482ba <+6>: push 0x10
0x080482bf <+11>: jmp 0x8048284
End of assembler dump.
So we see it's 0x8049580. We can patch our code for main() to change e8 11 ff ff ff 90 (address 0x8048e9e) to indirect call to GOT entry, i.e. call [ds:0x8049580]: ff 15 80 95 04 08:
(gdb) set *(uint64_t*)0x804839e=0x44830804958015ff
(gdb) disas/r
Dump of assembler code for function main:
...
0x08048397 <+19>: c7 04 24 80 84 04 08 mov DWORD PTR [esp],0x8048480
0x0804839e <+26>: ff 15 80 95 04 08 call DWORD PTR ds:0x8049580
0x080483a4 <+32>: 83 44 24 1c 01 add DWORD PTR [esp+0x1c],0x1
...
Running the program after this still gives:
(gdb) c
Continuing.
Hello
Hello
Hello
[Inferior 1 (process 14678) exited normally]
I.e. the first call did the lazy binding, and the next two just used the result of fixup (you can trace it yourself if you don't believe).
So the question remains: why is this way of calling not used by GCC?

Answer 1

Apparently, after binding the PLT entry to the function, we still do a two-step call:
call puts#plt
jmp [ds:puts_address]
The compiler and linker can't know that you are going to set LD_BIND_NOW=1 at runtime, and so can't go back in time and re-write generated code to use direct call [puts_address].
See also recent -fno-plt patches on the gcc-patches mailing list.
Win32
Win32 doesn't allow lazy function resolution (at least not by default). In other words, they compile / link code that only works as if LD_BIND_NOW=1 is hard-coded at compile / link time. Some history here.
it's still possible to have e.g. [puts_address] contain the call to _dl_runtime_resolve or whatever is needed on startup, so the one-step indirect call would still work.
I think you are confused. The [puts_address] does contain _dl_runtime_resolve at startup (well, not exactly. Gory details). Your question is "why can't the call go directly to [puts_address], why is puts#plt needed?".
The answer is that _dl_runtime_resolve needs to know which function it is resolving. It can't deduce that info from arguments to puts. The entire raison d'être of puts#plt is exactly to supply that info to _dl_runtime_resolve.
Update:
Why can't call <puts#plt> be replaced with call *[puts#GOT].
The answer is provided in the first -fno-plt patch I referenced:
"This comes with caveats. This cannot be generally done for all
functions marked extern as it is impossible for the compiler to say if
a function is "truly extern" (defined in a shared library). If a
function is not truly extern(ends up defined in the final executable),
then calling it indirectly is a performance penalty as it could have
been a direct call."
You could then ask: why can't the linker (which knows whether puts is defined in the same binary or in a separate DSO) rewrite the call *[puts#GOT] back into call <puts#plt>?
The answer is that these are different instructions (different op-codes), and linkers generally do not change instructions, only addresses within instructions (in response to relocation entries).
In theory the linker could do this, but no-one's bothered yet.