Why isn't all code compiled position independent?

Question

When compiling shared libraries in gcc the -fPIC option compiles the code as position independent. Is there any reason (performance or otherwise) why you would not compile

Answer 1

It adds an indirection. With position independent code you have to load the address of your function and then jump to it. Normally the address of the function is already present in the instruction stream.

Answer 2

In addition to the accepted answer. One thing that hurts PIC code performance a lot is the lack of "IP relative addressing" on x86. With "IP relative addressing" you could ask for data that is X bytes from the current instruction pointer. This would make PIC code a lot simpler.

Jumps and calls, are usually EIP relative, so those don't really pose a problem. However, accessing data will require a little extra trickery. Sometimes, a register will be temporarily reserved as a "base pointer" to data that the code requires. For example, a common technique is to abuse the way calls work on x86:

call label_1
.dd 0xdeadbeef
.dd 0xfeedf00d
.dd 0x11223344
label_1:
pop ebp            ; now ebp holds the address of the first dataword
                   ; this works because the call pushes the **next**
                   ; instructions address
                   ; real code follows
mov eax, [ebp + 4] ; for example i'm accessing the '0xfeedf00d' in a PIC way

This and other techniques add a layer of indirection to the data accesses. For example, the GOT (Global offset table) used by gcc compilers.

x86-64 added a "RIP relative" mode which makes things a lot simpler.

Answer 3

The question dates to 2009. Ten year have passed, and now all code is actually position independent. That is now enforced by operating systems and compilers. There is no way to opt-out. All code is force-compiled with PIE, and -no-pic/-no-pie flag is being ignored, as part of this ASLR excuse. The reason for that is to slow down formerly fast apps and sell newer hardware, under the guise of increased security. That is completely irrational, because now large memory sizes allow us to get rid of the hell of dynamic linking at all, compiling all apps statically.

Same happened before, when people silently accepted real mode and other freedoms being taking away. And I mind you, MMU incurs heavy slowdown, due to context switches and address translation latency. You won't find MMU in performance critical systems, like those used by scientists to sample physics experiments.

You don't complain, because you don't even know that your code is being handicapped by all these training wheels. What can I say? Enjoy 2 times slower software with their PIC now! Even more, with the advent of LLVM, soon there will be enforced JIT (managed code), with no access to x86 inline assembly, which will further slowdown any C/C++ code. "Those who sacrifice liberty for security deserve neither."