为什么 gcc 对 x64 共享库强制使用 PIC？

Question

尝试使用 gcc 将非 PIC 代码编译到 x64 上的共享库会导致错误，类似于：

/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

这个问题是关于为什么会这样。我知道 x64 有 RIP 相对寻址，旨在提高 PIC 代码的效率。但是，这并不意味着加载时重定位不能（理论上）应用于此类代码。

一些在线资源，包括这个（在这个问题上被广泛引用） ）声称存在一些固有的限制，禁止共享库中的非 PIC 代码，因为是 RIP 相对寻址。我不明白为什么这是真的。

考虑“旧的 x86”——call 指令也有一个与 IP 相关的操作数。然而，带有 call 的 x86 代码可以很好地编译成没有 PIC 的共享库，但使用 加载时重定位 R_386_PC32。不能对 x64 中的数据 RIP 相对寻址执行同样的操作吗？

请注意，我完全理解 PIC 代码的好处，并且 RIP 相对寻址的性能损失有助于减轻。不过，我很好奇不允许使用非 PIC 代码的原因。它背后是否有真正的技术原因，或者只是为了鼓励编写 PIC 代码？

Answer 1

这是我从 comp.unix.programmer 上的帖子中读到的最好的解释：

共享库需要 x86-64 上的 PIC，或更准确地说，需要可重定位代码
必须是PIC。这是因为 32 位立即地址操作数
重定位后代码中使用的可能需要超过 32 位。如果
发生这种情况时，没有地方可以写入新值。

Answer 2

补充一下吧。

在问题中提供的网址中，它提到您可以将 -mcmodel=large 传递给 gcc，告诉编译器为您的代码生成 64 位立即地址操作数。

因此，gcc -mcmodel=large -shared ac 将生成一个非 PIC 共享对象。

-

演示：

ac：

#include <stdio.h>

void foo(void)
{
    printf("%p\n", main);
}

32 位立即地址操作数阻止您生成非 PIC 对象。

xiami@gentoo ~ $ cc -shared -o a.so a.c
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/cck3FWeL.o: relocation R_X86_64_32 against `main' can not be used when making a shared object; recompile with -fPIC
/tmp/cck3FWeL.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

使用-mcmodel=large来解决。 （这些警告仅出现在我的系统上，因为我的 PaX 内核禁止对 .text 进行修改。）

xiami@gentoo ~ $ cc -mcmodel=large -shared -o a.so a.c
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccZ3b9Xk.o: warning: relocation in readonly section `.text'.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.4/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.

现在您可以看到重定位条目的类型是 R_X86_64_64，而不是 R_X86_64_32、R_X86_64_PLT32、R_X86_64_PLTOFF64。

xiami@gentoo ~ $ objdump -R a.so
a.so:      file format elf64-x86-64
DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE 
...
0000000000000758 R_X86_64_64       printf
...

在我的系统上，将此共享对象链接到普通代码并运行该程序将发出如下错误：
./a.out: 加载共享库时出错：./a.so: 无法使段可写以进行重定位：权限被拒绝

这证明动态加载器正在尝试对 .text< 进行重定位/strong> 哪个 PIC 库不会。

Answer 3

问题是，PIC 和非 PIC 代码仍然不同。

C 源代码：

extern int x;
void func(void) { x += 1; }

汇编，而不是 PIC：

addl    $1, x(%rip)

汇编，带有 PIC：

movq    x@GOTPCREL(%rip), %rax
addl    $1, (%rax)

所以看起来 PIC 代码必须通过重定位表才能访问全局变量。它实际上必须对函数执行相同的操作，但它可以通过在链接时创建的存根来执行函数。这在程序集级别是透明的，而访问全局变量则不然。 （但是，如果您需要函数的地址，那么 PIC 和非 PIC 是不同的，就像全局变量一样。）请注意，如果您按如下方式更改代码：

__attribute__((visibility("hidden"))) extern int x;

在这种情况下，因为 GCC 知道由于符号必须与代码驻留在同一对象中，因此它会发出与非 PIC 版本相同的代码。