c - 为什么链接会影响同一节内的相对跳转是否需要重定位？

Question

在这个简单的程序中，我在 main 中为 compute 进行了重定位，但没有为 compute2 进行了重定位:

static int compute2()
{
    return 2;
}

int compute()
{
    return 1;
}


int main()
{
    return compute() + compute2();
}

我在 Ubuntu 21.10 上使用 gcc 11.2.0 通过 gcc -c main.cpp 编译此文件。

以下是 objdump 关于 main 的说法:

000000000000001e <main>:
  1e:   f3 0f 1e fa             endbr64 
  22:   55                      push   rbp
  23:   48 89 e5                mov    rbp,rsp
  26:   53                      push   rbx
  27:   e8 00 00 00 00          call   2c <main+0xe>    28: R_X86_64_PLT32  compute()-0x4
  2c:   89 c3                   mov    ebx,eax
  2e:   e8 cd ff ff ff          call   0 <compute2()>
  33:   01 d8                   add    eax,ebx
  35:   48 8b 5d f8             mov    rbx,QWORD PTR [rbp-0x8]
  39:   c9                      leave  
  3a:   c3                      ret    

如您所见，对于compute2(内部链接)的调用，存在相对跳转，没有重定位。但对于compute(外部链接)的调用，即使所有三个函数都位于同一目标文件的同一部分，也会发生重定位。

为什么需要搬迁？我认为链接器永远不会分割一个部分，所以无论这个部分加载到哪里，相对地址应该仍然是相同的？为什么链接似乎会影响这个？

Answer 1

本身并不需要重定位，而是编译器选择通过PLT进行间接寻址(因为可能符号插入，或者如果主可执行文件或早期的共享库定义了该符号)。请注意重定位类型 R_X86_64_PLT32 .

如果您查看编译器的 asm 输出(而不是 .o 的反汇编)，您会看到 call compute@plt .

一个static函数肯定总是使用同一翻译单元中的定义，但全局符号的其他定义可以优先。

---

这应该只发生在 -fPIC 上，不适用于构建主可执行文件本身(-fPIE 在大多数现代发行版中默认处于启用状态)，适用于在同一 .c(翻译单元)中定义的符号。

https://godbolt.org/z/qYYWsYf6a显示 GCC -fPIE仍在使用call compute 。显然 Ubuntu 启用了一些其他选项来使这变得不同？ (Godbolt 的 gcc 默认情况下不会启用大多数发行版所做的一些功能，因此您需要一些选项来匹配 GCC 在 Ubuntu 上的配置方式。 -fstack-protector-strong 不相关，并且不知道还有什么。)

请注意，当链接可执行文件(不是共享库)时，调用应该“放松”为不通过 PLT 的直接调用。因此，GCC 可以将所有调用发出为 call foo@plt .

如果您使用-fno-plt同样，调用将发出为 call *foo@gotplt(%rip) ，需要 6 个字节，因此将其放宽为直接 5 字节调用 rel32 需要一个字节的填充符； ld 使用无意义的地址大小前缀。 (例如，请参阅我在 Can't call C standard library function on 64-bit Linux from assembly (yasm) code 上的回答。)

---

如果您一开始就不想使用此 PLT 间接寻址，则可以为该符号设置 ELF 可见性 = 隐藏。在创建共享库时，这是一个非常好的主意，因为在这种情况下，链接器将无法通过 PLT 放松所有间接调用，以进行您不打算允许符号插入的函数的内部调用。

您可以使用-fvisibility=hidden使其成为所有原型(prototype)的默认值，因此调用将使用 call rel32 ，而不是通过 PLT 间接(或使用 -fno-plt 的 GOT )。然后，对于共享库确实想要导出的任何函数或变量，请使用 __attribute__((visibility("default")))

对于您的情况， -fvisibility=hidden可能会解决您遇到的问题，即使您没有构建可以进入共享库的代码(使用 -fPIC )，GCC 也会不必要地间接。

另请参阅

• https://gcc.gnu.org/wiki/Visibility
• How to use the __attribute__((visibility("default")))?
• https://unix.stackexchange.com/questions/472660/what-are-difference-between-the-elf-symbol-visibility-levels
• Can't call C standard library function on 64-bit Linux from assembly (yasm) code (链接可执行文件而不是共享库时的链接时间松弛示例。)
• Sorry state of dynamic libraries on Linux在 Thiago Macieira 的博客上，从 2012 年开始。(在 -fno-plt 存在之前；所以至少这个想法已经实现，并且现在是某些发行版二进制包的默认设置，例如 Arch GNU/Linux。)