问题描述
试图编译非PIC code为在x64共享库，在一个错误 GCC 结果是这样的：
Trying to compile non-PIC code into a shared library on x64 with gcc results in an error, something like:
/usr/bin/ld: /tmp/ccQ2ttcT.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
这问题是关于为什么的是这样的。我知道，有64 RIP-相对寻址，旨在使PIC code更有效。然而，这并不意味着装载时重定位不能（在理论上）应用于这种code
This question is about why this is so. I know that x64 has RIP-relative addressing which was designed to make PIC code more efficient. However, this doesn't mean load-time relocation can't be (in theory) applied to such code.
一些网上消息人士透露，包括（这是在这个广泛引用问题）声称有禁止非PIC code共享库某些固有的局限性，因为的RIP相对寻址的。我不明白为什么这是真的。
Some online sources, including this one (which is widely quoted on this issue) claim that there's some inherent limitation prohibiting non-PIC code in shared libs, because of RIP-relative addressing. I don't understand why this is true.
考虑老86 - 一个呼叫指令也有一个IP相对操作数。然而，86 $ C $与呼叫下在它编译就好了，而不到一个PIC共享库，但使用的 R_386_PC32 。不能在同一对数据RIP相对寻址在64？做
Consider "old x86" - a call instruction also has an IP-relative operand. And yet, x86 code with call in it compiles just fine into a shared lib without PIC, but using the load-time relocation R_386_PC32. Can't the same be done for the data RIP-relative addressing in x64?
请注意，我完全理解PIC code的好处，以及性能损失RIP相对寻址有助于缓解。不过，我很好奇关于不允许使用非PIC code的原因。有一个背后的真正的技术推理，或只是鼓励写PIC code？
Note that I fully understand the benefits of PIC code, and the performance penalty RIP-relative addressing helps alleviate. Still, I'm curious about the reason for not allowing using non-PIC code. Is there a real technical reasoning behind it, or is it just to encourage writing PIC code?
推荐答案
下面是我从的一个帖子：
Here is the best explanation I've read from a post on comp.unix.programmer:
共享库需要PIC上的x86-64，或者更准确地说，重定位code
已成为事先知情同意。这是因为32位立即操作数地址
在code用于搬迁后可能需要超过32位。如果
出现这种情况，也没有地方写新的值。
这篇关于为什么GCC力PIC用于基于x64的共享库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！