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

27
votes

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 former?

3
clinuxx86x86-64elf
I've never understood this. If the compiler can tell you exactly what option to use automatically, why does it require that you say magic words to make it operate correctly? Grrr.. – Billy ONeal
@Billy ONeal, Now I believe that's the case of leaky abstraction. They differ in how they load global data, which affects whether PIC is needed or not. – Alex B
I understand the need for the difference. What I don't understand is why you need to give the compiler a switch to make it do that. – Billy ONeal
@Billy, the error comes from the linker – Gearoid Murphy
@GearoidMurphy: Okay, 6 of this, half dozen of another. The compilation was invoked with a single call to g++ (rather than calls to the compiler and linker separately), so g++ should easily be able to tell if some compiler option is going to require a corresponding linker option. – Billy ONeal

3 Answers

21
votes

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.
4
votes

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). .

1
votes

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.