聊聊Linux动态链接中的PLT和GOT(3)——公共GOT表项

前文(聊聊Linux动态链接中的PLT和GOT(2)——延迟重定位)提到所有动态库函数的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 <_GLOBAL_OFFSET_TABLE_+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 <_GLOBAL_OFFSET_TABLE_+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表的

前2个问题,只需要一个信息就可以了知道,这个信息就在藏在在函数对应的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

这3个push操作数刚好对应3个函数在.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表项还保留了3个公共表项,也即got的前3项,分别保存:

got[0]: 本ELF动态段(.dynamic段)的装载地址
got[1]:本ELF的link_map数据结构描述符地址
got[2]:_dl_runtime_resolve函数的地址

动态链接器在加载完ELF之后,都会将这3地址写到GOT表的前3项。
其实上述公共的plt指令里面,还有一个操作数是没有分析的,其实它就是got[1](本ELF的link_map)地址,因为只有link_map结构,结合.rel.plt段的偏移量,才能真正找到该elf的.rel.plt表项。

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

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

你可能感兴趣的:(聊聊glibc,plt,got,ld-linux,动态链接,动态链接器)