为什么除了GOT之外还存在PLT，而不仅仅是使用GOT? [英] Why does the PLT exist in addition to the GOT, instead of just using the GOT?

问题描述

我知道在典型的ELF二进制文件中，函数是通过过程链接表(PLT)调用的.函数的PLT条目通常包含到全局偏移表(GOT)条目的跳转.此项将首先引用一些代码，以将实际功能地址加载到GOT中，并在首次调用(延迟绑定)后包含实际功能地址.

I understand that in a typical ELF binary, functions get called through the Procedure Linkage Table (PLT). The PLT entry for a function usually contains a jump to a Global Offset Table (GOT) entry. This entry will first reference some code to load the actual function address into the GOT, and contain the actual function address after the first call (lazy binding).

准确地说，在延迟绑定GOT条目之前，请先将其指向PLT，然后再跳转至GOT.这些指令通常会跳到PLT的开头，从那里调用一些绑定例程，然后该绑定例程将更新GOT条目.

To be precise, before lazy binding the GOT entry points back into the PLT, to the instructions following the jump into the GOT. These instructions will usually jump to the head of the PLT, from where some binding routine gets called which will then update the GOT entry.

现在，我想知道为什么有两种间接方式(调用PLT，然后从GOT跳转到地址)，而不是仅仅保留PLT并直接从GOT调用地址.看起来这可以节省跳转和完整的PLT.当然，您仍然需要一些代码来调用绑定例程，但这可以在PLT之外.

Now I'm wondering why there are two indirections (calling into the PLT and then jumping to an address from the GOT), instead of just sparing the PLT and calling the address from the GOT directly. It looks like this could save a jump and the complete PLT. You would of course still need some code calling the binding routine, but this can be outside the PLT.

有什么我想念的吗?额外的PLT的目的是/目的是什么?

Is there anything I am missing? What is/was the purpose of an extra PLT?

更新: 正如评论中所建议的那样，我创建了一些(伪)代码ASCII艺术，以进一步解释我所指的内容:

Update: As suggested in the comments, I created some (pseudo-) code ASCII art to further explain what I'm referring to:

据我所知，在当前的PLT方案中，这是延迟绑定之前的情况:(PLT和printf之间的某些间接表示为"...".)

This is the situation, as far as I understand it, in the current PLT scheme before lazy binding: (Some indirections between the PLT and printf are represented by "...".)

Program                PLT                                 printf
+---------------+      +------------------+                +-----+
| ...           |      | push [0x603008]  |<---+       +-->| ... |
| call j_printf |--+   | jmp [0x603010]   |----+--...--+   +-----+
| ...           |  |   | ...              |    |
+---------------+  +-->| jmp [printf@GOT] |-+  |
                       | push 0xf         |<+  |
                       | jmp 0x400da0     |----+
                       | ...              |
                       +------------------+

…以及延迟绑定后:

Program                PLT                       printf
+---------------+      +------------------+      +-----+
| ...           |      | push [0x603008]  |  +-->| ... |
| call j_printf |--+   | jmp [0x603010]   |  |   +-----+
| ...           |  |   | ...              |  |
+---------------+  +-->| jmp [printf@GOT] |--+
                       | push 0xf         |
                       | jmp 0x400da0     |
                       | ...              |
                       +------------------+

在我没有PLT的虚构替代方案中，延迟绑定之前的情况如下:(我将代码保存在"Lazy Binding Table"中，类似于PLT中的代码.不在乎.)

In my imaginary alternative scheme without a PLT, the situation before lazy binding would look like this: (I kept the code in the "Lazy Binding Table" similar to to the one from the PLT. It could also look differently, I don't care.)

Program                    Lazy Binding Table                printf
+-------------------+      +------------------+              +-----+
| ...               |      | push [0x603008]  |<-+       +-->| ... |
| call [printf@GOT] |--+   | jmp [0x603010]   |--+--...--+   +-----+
| ...               |  |   | ...              |  |
+-------------------+  +-->| push 0xf         |  |
                           | jmp 0x400da0     |--+
                           | ...              |
                           +------------------+

现在，在延迟绑定之后，就不再使用该表了:

Now after the lazy binding, one wouldn't use the table anymore:

Program                   Lazy Binding Table        printf
+-------------------+     +------------------+      +-----+
| ...               |     | push [0x603008]  |  +-->| ... |
| call [printf@GOT] |--+  | jmp [0x603010]   |  |   +-----+
| ...               |  |  | ...              |  |
+-------------------+  |  | push 0xf         |  |
                       |  | jmp 0x400da0     |  |
                       |  | ...              |  |
                       |  +------------------+  |
                       +------------------------+

推荐答案

问题在于，用call [printf@GOTPLT]替换call printf@PLT要求编译器知道函数printf存在于共享库中，而不是静态库中(甚至只是在一个普通的目标文件中).链接器可以将call printf更改为call printf@PLT，将jmp printf更改为jmp printf@PLT甚至将mov eax, printf更改为mov eax, printf@PLT，因为它所做的全部工作就是将基于符号printf的重定位更改为基于符号<的重定位. c11>.链接器无法将call printf更改为call [printf@GOTPLT]，因为它无法从重定位中得知它是CALL还是JMP指令或完全是其他指令.不知道它是否是CALL指令，就不知道是否应该将操作码从直接CALL更改为间接CALL.

The problem is that replacing call printf@PLT with call [printf@GOTPLT] requires that the compiler knows that the function printf exists in a shared library and not a static library (or even in just a plain object file). The linker can change call printf into call printf@PLT, jmp printf into jmp printf@PLT or even mov eax, printf into mov eax, printf@PLT because all it's doing it changing a relocation based on the symbol printf into relocation based on the symbol printf@PLT. The linker can't change call printf into call [printf@GOTPLT] because it doesn't know from the relocation whether it's a CALL or JMP instruction or something else entirely. Without knowing whether it's a CALL instruction or not, it doesn't know whether it should change the opcode from a direct CALL to a indirect CALL.

但是，即使有一种特殊的重定位类型表明该指令是CALL，您仍然有一个问题，即直接调用指令的长度为5个字节，而间接调用指令的长度为6个字节.编译器将必须发出类似nop; call printf@CALL的代码，以提供链接器空间来插入所需的附加字节，并且它必须对任何对全局函数的所有调用进行此操作.由于所有额外且不是必需的NOP指令，最终可能会导致净性能损失.

However even if there was a special relocation type that indicated that the instruction was a CALL, you still have the problem that a direct call instruction is a 5 bytes long but a indirect call instruction is 6 bytes long. The compiler would have to emit code like nop; call printf@CALL to give the linker room to insert the additional byte needed and it would have to do it for all calls to any global function. It would probably end up being a net performance loss because of all the extra and not actually necessary NOP instructions.

另一个问题是在32位x86目标上，PLT条目在运行时被重定位. PLT中的间接jmp [xxx@GOTPLT]指令不使用直接CALL和JMP指令那样的相对寻址，并且由于xxx@GOTPLT的地址取决于图像在内存中的加载位置，因此该指令需要固定才能使用正确的地址.通过将所有这些间接JMP指令组合在一个.plt节中，意味着需要修改的虚拟内存页面数量要少得多.修改后的每个4K页面无法再与其他进程共享，当需要修改的指令散布在整个内存中时，它要求更大一部分图像不共享.

Another problem is that on 32-bit x86 targets the PLT entries are relocated at runtime. The indirect jmp [xxx@GOTPLT] instructions in the PLT don't use relative addressing like the direct CALL and JMP instructions, and since the address of xxx@GOTPLT depends on where the image was loaded in memory the instruction needs to be fixed up to use the correct address. By having all these indirect JMP instructions grouped together in one .plt section means that much smaller number of virtual memory pages need to be modified. Each 4K page that's modified can no longer be shared with other processes, when the instructions that need to modified are scattered all over memory it requires that a much larger part the image to be unshared.

请注意，以后的问题仅是共享库和32位x86目标上与位置无关的可执行文件的问题.传统的可执行文件无法重定位，因此无需修复@GOTPLT引用，而在64位x86目标上，RIP相对地址用于访问@GOTPLT条目.

Note that this later issue is only a problem with shared libraries and position independent executables on 32-bit x86 targets. Traditional executables can't be relocated, so there's no need to fix the @GOTPLT references, while on 64-bit x86 targets RIP relative addressing is used to access the @GOTPLT entries.

由于最后一点，GCC的新版本(6.1或更高版本)支持-fno-plt标志.在64位x86目标上，此选项使编译器生成call printf@GOTPCREL[rip]指令而不是call printf指令.但是，对于未在同一编译单元中定义的任何函数调用，似乎都可以执行此操作.那是肯定不知道在共享库中没有定义的任何函数.这意味着间接跳转也将用于对其他目标文件或静态库中定义的函数的调用.在32位x86目标上，除非编译位置无关代码(-fpic或-fpie)会导致发出call printf@GOT[ebx]指令，否则将忽略-fno-plt选项.除了产生不必要的间接跳转外，这还具有需要为GOT指针分配寄存器的缺点，尽管大多数功能无论如何都需要分配它.

Because of that last point new versions of a GCC (6.1 or later) support the -fno-plt flag. On 64-bit x86 targets this option causes the compiler to generate call printf@GOTPCREL[rip] instructions instead of call printf instructions. However it appears to do this for any call to a function that isn't defined in the same compilation unit. That is any function it doesn't know for sure isn't defined in shared library. That would mean that indirect jumps would also be used for calls to functions defined in other object files or static libraries. On 32-bit x86 targets the -fno-plt option is ignored unless compiling position independent code (-fpic or -fpie) where it results in call printf@GOT[ebx] instructions being emitted. In addition to generating unnecessary indirect jumps, this also has the disadvantage of requiring the allocation of a register for the GOT pointer though most functions would need it allocated anyways.

最后，Windows可以通过使用"dllimport"属性在头文件中声明符号来表明您的建议，这些符号表明它们存在于DLL中.这样，编译器知道在调用函数时是否生成直接或间接调用指令.这样做的缺点是符号必须存在于DLL中，因此，如果使用此属性，则无法在编译后决定与静态库链接.

Finally, Windows is able to do what you suggest by declaring symbols in header files with the "dllimport" attribute, indicating that they exist in DLLs. This way the compiler knows whether or not to generate direct or indirect call instruction when calling the function. The disadvantage of this is that the symbol has to exist in a DLL, so if this attribute used is you can't decide after compilation to link with a static library instead.

也请阅读Drepper的 如何编写共享库 论文，它对此进行了很好的解释(对于Linux).

Read also Drepper's How to write a shared library paper, it explains that quite well in details (for Linux).

这篇关于为什么除了GOT之外还存在PLT，而不仅仅是使用GOT?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！