动态链接库的优点比较明显,主要集中在节省内存,简化对程序的管理等,对此感兴趣的看官可以去阅读经典的教材 Linker and Loader,国内也有一本经典的教材,俞甲子 石凡 潘爱民编著的程序员的自我修养,讲的也非常好。
延迟绑定PLT,我迷惑过很久,终于让我遇到一篇写的非常棒的博文,这就是 Position Indepentent code in share library.作者对编译链接的理解十分深刻,写了一个系列的文章,英文水平好的读者可以不听我唠叨,直接看英文原文。我这篇文章主要参考提到的博文,同时参考的程序员的自我修养,即网上的其他博文,做了下实验,对位置无关共享库的理解加深了一大步。说这些的原因是不想陷入版权纠纷,本文所有的东西,基本是学习其他博文 书籍的产物,版权不属于我,版权属于前辈。我做的只是将前辈的讲解综合以下,互相补充。
动态链接技术,严格的说分成两类,一种是 Load-Time Relocation,这种技术容易理解,但是缺点也比较致命,不能共享,起不到节省内存的目的,目前X86_64已经不提供这种方式;另外一种属于主流的位置无关(PIC)动态库。
位置无关动态库中,有两个需要解决的问题,一个是动态库中的变量如何访问,另一个是动态库中的函数调用如何访问。其实,我们一般调用的是动态库中的函数,别的不说,printf是libc库提供的函数,当我们调用printf的时候,我们如何找到函数的地址的呢? 这就是本文主要讲述的内容。
前面提到了延迟绑定,何为延迟绑定呢。这个也比较好理解。libc库中有很多的函数,但是我们编写程序的时候,并不一定会调用libc库中的每个函数,更多的情况下,我们只调用了极少数函数,如果我们将每个函数的地址都解析出来,其实是一种浪费。所以采用的方法是用到函数时再进行对函数的位置进行定位。 这种技术就叫做延迟定位。
我下面的代码用的是Position Indepentent code in share library博文中的代码,再次强调,版权和荣耀,都属于前辈。
ml_main.c
- int myglob = 42;
-
-
int ml_util_func(int a)
-
{
-
return a + 1;
-
}
-
int ml_func(int a, int b)
-
{
-
int c = b + ml_util_func(a);
-
myglob += c;
-
return b + myglob;
-
}
- gcc -shared -fpic -g libmlpic.so ml_main.c
解释下上面的命令,-shared参数表示生成共享库, -fpic参数表示生成位置无关动态库,前面也提到了,存在两种类型的动态库,如果不带-fpic,那么,生成的是装载时重定位共享库。当然了fpic和fPIC也有区别,这个不是我们关心的内容,不赘述。
driver.c
- #define _GNU_SOURCE
-
#include <link.h>
-
#include <stdlib.h>
-
#include <stdio.h>
-
#include<time.h>
-
static int header_handler(struct dl_phdr_info* info, size_t size, void* data)
-
{
-
int j;
-
printf("name=%s (%d segments) address=%p\n",
-
info->dlpi_name, info->dlpi_phnum, (void*)info->dlpi_addr);
-
for ( j = 0; j < info->dlpi_phnum; j++) {
-
printf("\t\t header %2d: address=%10p\n", j,
-
(void*) (info->dlpi_addr + info->dlpi_phdr[j].p_vaddr));
-
printf("\t\t\t type=%u, flags=0x%X\n",
-
info->dlpi_phdr[j].p_type, info->dlpi_phdr[j].p_flags);
-
}
-
printf("\n");
-
return 0;
-
}
-
-
extern int ml_func(int, int);
-
-
int main(int argc, const char* argv[])
-
{
-
dl_iterate_phdr(header_handler, NULL);
-
-
int t = ml_func(argc, argc);
- sleep(12);
-
return t;
-
}
- gcc -o driver -g driver.c ./libmlpic.so
我们生成了可执行程序driver,driver调用了共享库libmlpic.so中的函数ml_func。
- (gdb) disas main
-
Dump of assembler code for function main:
-
0x08048697 <+0>: push %ebp
-
0x08048698 <+1>: mov %esp,%ebp
-
0x0804869a <+3>: and $0xfffffff0,%esp
-
0x0804869d <+6>: sub $0x20,%esp
-
0x080486a0 <+9>: movl $0x0,0x4(%esp)
-
0x080486a8 <+17>: movl $0x80485c4,(%esp)
-
0x080486af <+24>: call 0x80484fc
-
=> 0x080486b4 <+29>: mov 0x8(%ebp),%eax
-
0x080486b7 <+32>: mov %eax,0x4(%esp)
-
0x080486bb <+36>: mov 0x8(%ebp),%eax
-
0x080486be <+39>: mov %eax,(%esp)
-
0x080486c1 <+42>: call 0x804849c
-
0x080486c6 <+47>: mov %eax,0x1c(%esp)
-
0x080486ca <+51>: movl $0xc,(%esp)
-
0x080486d1 <+58>: call 0x80484ec
-
0x080486d6 <+63>: mov 0x1c(%esp),%eax
-
0x080486da <+67>: leave
-
0x080486db <+68>: ret
-
End of assembler dump.
我们要调用ml_func函数,但是@plt表明是动态库中的函数,0x804849c是地址,我们反汇编下
- Breakpoint 1, 0x080486c1 in main (argc=1, argv=0xbffff7e4) at driver.c:27
-
27 int t = ml_func(argc, argc);
-
-
(gdb) disas 0x804849c
-
Dump of assembler code for function ml_func@plt:
-
0x0804849c <+0>: jmp *0x804a000
-
0x080484a2 <+6>: push $0x0
-
0x080484a7 <+11>: jmp 0x804848c
-
End of assembler dump.
-
(gdb) x 0x804a000
-
0x804a000 <_GLOBAL_OFFSET_TABLE_+12>: 0x080484a2
理想情况下,0x8048a00存放的是ml_func函数的地址,但是0x80484a2这个地址并不是ml_func函数的地址。所谓延迟绑定的意思就是,并不是一开始就将所有的函数的地址解析好,而是第一次调用库函数时,将库函数的实际地址绑定到GOT的指定位置。
我们看到0x8048a00地址是_GLOBAL_OFFSET_TABLE+12,这个可以算出,_GLOBAL_OFFSET_TABLE地址为 0x80489ff4.
- (gdb) x/20x 0x8049FF4
-
0x8049ff4 <_GLOBAL_OFFSET_TABLE_>: 0x08049f18 0x0012c8f8 0x00123220 0x080484a2 - -地址并不是真正 的ml_func的地址。
-
0x804a004 <_GLOBAL_OFFSET_TABLE_+16>: 0x080484b2 0x0018fb70 0x00147af0 0x00178130
-
0x804a014 <_GLOBAL_OFFSET_TABLE_+32>: 0x080484f2 0x00234e10 0x00000000 0x00000000
-
0x804a024 : 0x00000000 0x00000000 0x00000000 0x00000000
-
0x804a034: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb) x/30i 0x804848c
0x804848c: pushl 0x8049ff8
0x8048492: jmp *0x8049ffc
0x8048498: add %al,(%eax)
0x804849a: add %al,(%eax)
0x804849c : jmp *0x804a000
0x80484a2 : push $0x0 -----跳到此处,发现不是函数地址,跳转后调 用_dl_runtime_resolve
0x80484a7 : jmp 0x804848c
0x80484ac <__gmon_start__@plt>: jmp *0x804a004
0x80484b2 <__gmon_start__@plt+6>: push $0x8
0x80484b7 <__gmon_start__@plt+11>: jmp 0x804848c
0x80484bc
: jmp *0x804a008 0x80484c7
: jmp 0x804848c 0x80484cc <__libc_start_main@plt>: jmp *0x804a00c
0x80484d2 <__libc_start_main@plt+6>: push $0x18
0x80484d7 <__libc_start_main@plt+11>: jmp 0x804848c
0x80484dc
: jmp *0x804a010 0x80484e7
: jmp 0x804848c 0x80484ec : jmp *0x804a014
0x80484f2 : push $0x28
0x80484f7 : jmp 0x804848c
0x80484fc
: jmp *0x804a018 0x8048507
: jmp 0x804848c 0x804850c: add %al,(%eax)
0x804850e: add %al,(%eax)
我们看到0x80484a2处,不是函数地址,而是push 0x0,然后跳转到了0x804848c,然后,将另一个参数动态库的模块ID压栈后,调用传说中的_dl_runtime_resolve,来 获取函数的真正地址。0x123220就是_dl_runtime_resolve的地址,可以看下程序员的自我修养,.got.plt的前三项的特殊含义的说明。
- (gdb) b * 0x00123220
-
Breakpoint 2 at 0x123220: file ../sysdeps/i386/dl-trampoline.S, line 29.
-
(gdb) c
-
Continuing.
-
-
Breakpoint 2, _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:29
-
29 ../sysdeps/i386/dl-trampoline.S: 没有那个文件或目录.
-
in ../sysdeps/i386/dl-trampoline.S
-
(gdb) disas 0x00123220
-
Dump of assembler code for function _dl_runtime_resolve:
-
=> 0x00123220 <+0>: push %eax
-
0x00123221 <+1>: push %ecx
-
0x00123222 <+2>: push %edx
-
0x00123223 <+3>: mov 0x10(%esp),%edx
-
0x00123227 <+7>: mov 0xc(%esp),%eax
-
0x0012322b <+11>: call 0x11d550 <_dl_fixup>
-
0x00123230 <+16>: pop %edx
-
0x00123231 <+17>: mov (%esp),%ecx
-
0x00123234 <+20>: mov %eax,(%esp)
-
0x00123237 <+23>: mov 0x4(%esp),%eax
-
0x0012323b <+27>: ret $0xc
-
End of assembler dump.
我们看到的,_dl_runtime_resolve调用的_dl_fixup,来修改GOT表中的表项,还记的
- (gdb) x 0x804a000
-
0x804a000 <_GLOBAL_OFFSET_TABLE_+12>: 0x080484a2
执行完,之后,我们看下
- (gdb) x/20x 0x8049FF4
-
0x8049ff4 <_GLOBAL_OFFSET_TABLE_>: 0x08049f18 0x0012c8f8 0x00123220 0x0012e4a7 ----这回这个地址就是ml_func的 地址
-
0x804a004 <_GLOBAL_OFFSET_TABLE_+16>: 0x080484b2 0x0018fb70 0x00147af0 0x00178130
-
0x804a014 <_GLOBAL_OFFSET_TABLE_+32>: 0x080484f2 0x00234e10 0x00000000 0x00000000
-
0x804a024 : 0x00000000 0x00000000 0x00000000 0x00000000
-
0x804a034: 0x00000000 0x00000000 0x00000000 0x00000000
我们看到GOT发生了变化,第四项内容从原来的0x80484a2变成了,0x0012e4a7,这个地址,就是传说中的ml_func的地址,我们验证下:
- (gdb) p &ml_func
-
$1 = (int (*)(int, int)) 0x12e4a7
Bingo,这就是一个完整的PLT的过程,对_dl_runtime_resolve函数感兴趣的兄弟可以继续深究。
参考文献:
1 程序员的自我修养
2
阅读(537) | 评论(0) | 转发(0) |