前文(聊聊Linux动态链接中的PLT和GOT(２)——延迟重定位)提到所有动态库函数的plt指令最终都跳进公共plt执行，那么公共plt指令里面的地址是什么鬼？

把test可执行文的共公plt贴出来：

080482a0 :

80482a0: pushl 0x80496f0

80482a6: jmp *0x80496f4

...

第一句，pushl 0x80496f0，是将地址压到栈上，也即向最终调用的函数传递参数。

第二句，jmp *0x80496f4，这是跳到最终的函数去执行，不过猜猜就能想到，这是跳到能解析动态库函数地址的代码里面执行。

0x80496f4里面住着是何方圣呢？下面使用gdb调试器将它请出来：

$ gdb -q ./test

...

(gdb)x/xw 0x80496f4

0x80496f4 8>: 0x00000000

(gdb) b main

Breakpoint 1 at 0x80483f3

(gdb) r

Starting program: /home/ivan/test/test/test

Breakpoint 1, 0x80483f3 in main ()

(gdb) x/xw 0x80496f4

0x80496f4 8>: 0xf7ff06a0

从调试过程可以发现，0x80496f4属于GOT表中的一项，进程还没有运行时它的值是0x00000000，当进程运行起来后，它的值变成了0xf7ff06a0。如果做更进一步的调试会发现这个地址位于动态链接器内，对应的函数是_dl_runtime_resolve。

嗯，是不是想到了什么呢。所有动态库函数在第一次调用时，都是通过XXX@plt -> 公共@plt -> _dl_runtime_resolve调用关系做地址解析和重定位的。

谈到这里，其实还有谜底是没有解开的，以printf函数为例：

_dl_runtime_resolve是怎么知要查找printf函数的

_dl_runtime_resolve找到printf函数地址之后，它怎么知道回填到哪个GOT表项

到底_dl_runtime_resolve是什么时候被写到GOT表的

前２个问题，只需要一个信息就可以了知道，这个信息就在藏在在函数对应的xxx@plt表中，以printf@plt为例：

printf@plt>:

jmp *0x80496f8

push $0x00

jmp common@plt

第二条指令就是秘密所在，每个xxx@plt的第二条指令push的操作数都是不一样的，它就相当于函数的id，动态链接器通过它就可以知道是要解析哪个函数了。

真有这么神吗？这不是神，是编译链接器和动态链接器故意安排的巧合罢了。

使用readelf -r test命令可以查看test可执行文件中的重定位信息，其中.rel.plt这一段就大有秘密：

$ readelf -r test

....

Relocation section '.rel.plt' at offset 0x25c contains 3 entries:

Offset Info Type Sym.Value Sym. Name

080496f8 00000107 R_386_JUMP_SLOT 00000000 puts

080496fc 00000207 R_386_JUMP_SLOT 00000000 __gmon_start__

08049700 00000407 R_386_JUMP_SLOT 000000000 __libc_start_main

再看看各函数plt指令中的push操作数：

printf对应push 0x0

gmon_start对应push 0x8

__libc_start_main对应push 0x10

这３个push操作数刚好对应３个函数在.rel.plt段的偏移量。在_dl_runtime_resolve函数内，根据这个offset和.rel.plt段的信息，就知道要解析的函数。再看看.rel.plt最左边的offset字段，它就是GOT表项的地址，也即_dl_runtime_resolve做完符号解析之后，重定位回写的空间。

第三个问题：到底_dl_runtime_resolve是什么时候被写到GOT表的。

答案很简单，可执行文件在Linux内核通过exeve装载完成之后，不直接执行，而是先跳到动态链接器(ld-linux-XXX)执行。在ld-linux-XXX里将_dl_runtime_resolve地址写到GOT表项内。

事实上，不单单是预先写_dl_runtime_resolve地址到GOT表项中，在i386架构下，除了每个函数占用一个GOT表项外，GOT表项还保留了３个公共表项，也即got的前３项，分别保存：

got[0]: 本ELF动态段(.dynamic段)的装载地址

got[1]：本ELF的link_map数据结构描述符地址

got[2]：_dl_runtime_resolve函数的地址

动态链接器在加载完ELF之后，都会将这３地址写到GOT表的前３项。

其实上述公共的plt指令里面，还有一个操作数是没有分析的，其实它就是got[1](本ELF的link_map)地址，因为只有link_map结构，结合.rel.plt段的偏移量，才能真正找到该elf的.rel.plt表项。

有兴趣的读者可以使用gdb，在执行到main函数时，将GOT表的这３项数据看一下，验证一下。

好了，谈到这里是否对PLT和GOT机制有个更清晰认识了呢？最后一篇会使用图文结构将整个PLT/GOT机制串起来。