Difference in position-independent code: x86 vs x86-64

I was recently building a certain shared library (ELF) targeting x86-64 architecture, like this:

g++ -o binary.so -shared --no-undefined ... -lfoo -lbar

This failed with the following error:

relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC

Of course, it means I need to rebuild it as position-independent code, so it's suitable for linking into a shared library.

But this works perfectly well on x86 with exactly the same build arguments. So the question is, how is relocation on x86 different from x86-64 and why don't I need to compile with -fPIC on the开发者_如何学Python former?

I have found a nice and detailed explanation, which boils down to:

1. x86-64 uses IP-relative offset to load global data, x86-32 cannot, so it dereferences a global offset.
2. IP-relative offset does not work for shared libraries, because global symbols can be overridden, so x86-64 breaks down when not built with PIC.
3. If x86-64 built with PIC, the IP-relative offset dereference now yields a pointer to GOT entry, which is then dereferenced.
4. x86-32, however, already uses a dereference of a global offset, so it is turned into GOT entry directly.

It is a code model issues. By default, static code is build assuming the whole program will stay in the lower 2G part of the memory address space. Code for shared libraries need to be compiled for another memory model, either PIC, or with -mcmodel=large which will compile without making that assumption.

Note that -mcmodel=large is not implemented in older gcc version (it is in 4.4, it isn't in 4.2, I don't know for 4.3). .

It's purely an arbitrary requirement the ABI people have imposed on us. There's no logical reason why the dynamic linker on x86_64 couldn't support non-PIC libraries. However, since x86_64 is not under such horrible register pressure as x86 (and has better features for PIC), I don't know of any significant reason not to use PIC.