Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1743
  • 博文数量: 1
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 10
  • 用 户 组: 普通用户
  • 注册时间: 2018-07-07 12:02
文章分类
文章存档

2018年(1)

我的朋友
最近访客

分类: LINUX

2018-07-07 12:03:46

    动态链接库的优点比较明显,主要集中在节省内存,简化对程序的管理等,对此感兴趣的看官可以去阅读经典的教材 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
  1. int myglob = 42;

  2. int ml_util_func(int a)
  3. {
  4.     return a + 1;
  5. }
  6. int ml_func(int a, int b)
  7. {
  8.                 int c = b + ml_util_func(a);
  9.                 myglob += c;
  10.                 return b + myglob;
  11. }
  1. gcc -shared -fpic -g libmlpic.so ml_main.c
       解释下上面的命令,-shared参数表示生成共享库, -fpic参数表示生成位置无关动态库,前面也提到了,存在两种类型的动态库,如果不带-fpic,那么,生成的是装载时重定位共享库。当然了fpic和fPIC也有区别,这个不是我们关心的内容,不赘述。

driver.c
  1. #define _GNU_SOURCE
  2. #include <link.h>
  3. #include <stdlib.h>
  4. #include <stdio.h>
  5. #include<time.h>
  6. static int header_handler(struct dl_phdr_info* info, size_t size, void* data)
  7. {
  8.                 int j;
  9.                 printf("name=%s (%d segments) address=%p\n",
  10.                                                 info->dlpi_name, info->dlpi_phnum, (void*)info->dlpi_addr);
  11.                 for ( j = 0; j < info->dlpi_phnum; j++) {
  12.                                 printf("\t\t header %2d: address=%10p\n", j,
  13.                                                                 (void*) (info->dlpi_addr + info->dlpi_phdr[j].p_vaddr));
  14.                                 printf("\t\t\t type=%u, flags=0x%X\n",
  15.                                                                 info->dlpi_phdr[j].p_type, info->dlpi_phdr[j].p_flags);
  16.                 }
  17.                 printf("\n");
  18.                 return 0;
  19. }

  20. extern int ml_func(int, int);

  21. int main(int argc, const char* argv[])
  22. {
  23.                 dl_iterate_phdr(header_handler, NULL);

  24.                 int t = ml_func(argc, argc);
  25.                 sleep(12);
  26.                 return t;
  27. }

  1. gcc -o driver -g driver.c ./libmlpic.so
    我们生成了可执行程序driver,driver调用了共享库libmlpic.so中的函数ml_func。

  1. (gdb) disas main
  2. Dump of assembler code for function main:
  3. 0x08048697 <+0>: push %ebp
  4. 0x08048698 <+1>: mov %esp,%ebp
  5. 0x0804869a <+3>: and $0xfffffff0,%esp
  6. 0x0804869d <+6>: sub $0x20,%esp
  7. 0x080486a0 <+9>: movl $0x0,0x4(%esp)
  8. 0x080486a8 <+17>: movl $0x80485c4,(%esp)
  9. 0x080486af <+24>: call 0x80484fc
  10. => 0x080486b4 <+29>: mov 0x8(%ebp),%eax
  11. 0x080486b7 <+32>: mov %eax,0x4(%esp)
  12. 0x080486bb <+36>: mov 0x8(%ebp),%eax
  13. 0x080486be <+39>: mov %eax,(%esp)
  14. 0x080486c1 <+42>: call 0x804849c
  15. 0x080486c6 <+47>: mov %eax,0x1c(%esp)
  16. 0x080486ca <+51>: movl $0xc,(%esp)
  17. 0x080486d1 <+58>: call 0x80484ec
  18. 0x080486d6 <+63>: mov 0x1c(%esp),%eax
  19. 0x080486da <+67>: leave
  20. 0x080486db <+68>: ret
  21. End of assembler dump.
    
      我们要调用ml_func函数,但是@plt表明是动态库中的函数,0x804849c是地址,我们反汇编下

  1. Breakpoint 1, 0x080486c1 in main (argc=1, argv=0xbffff7e4) at driver.c:27
  2. 27                    int t = ml_func(argc, argc);

  3. (gdb) disas 0x804849c
  4. Dump of assembler code for function ml_func@plt:
  5.    0x0804849c <+0>:    jmp *0x804a000
  6.    0x080484a2 <+6>:    push $0x0
  7.    0x080484a7 <+11>:   jmp 0x804848c
  8. End of assembler dump.
  9. (gdb) x 0x804a000
  10. 0x804a000 <_GLOBAL_OFFSET_TABLE_+12>:    0x080484a2
     理想情况下,0x8048a00存放的是ml_func函数的地址,但是0x80484a2这个地址并不是ml_func函数的地址。所谓延迟绑定的意思就是,并不是一开始就将所有的函数的地址解析好,而是第一次调用库函数时,将库函数的实际地址绑定到GOT的指定位置。 

    我们看到0x8048a00地址是_GLOBAL_OFFSET_TABLE+12,这个可以算出,_GLOBAL_OFFSET_TABLE地址为 0x80489ff4.
  1. (gdb) x/20x 0x8049FF4
  2. 0x8049ff4 <_GLOBAL_OFFSET_TABLE_>: 0x08049f18 0x0012c8f8 0x00123220 0x080484a2           - -地址并不是真正                                                                                           的ml_func的地址。
  3. 0x804a004 <_GLOBAL_OFFSET_TABLE_+16>: 0x080484b2 0x0018fb70 0x00147af0 0x00178130
  4. 0x804a014 <_GLOBAL_OFFSET_TABLE_+32>: 0x080484f2 0x00234e10 0x00000000 0x00000000
  5. 0x804a024 : 0x00000000 0x00000000 0x00000000 0x00000000
  6. 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
   0x80484c2 : push   $0x10
   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
   0x80484e2 : push   $0x20
   0x80484e7 : jmp    0x804848c
   0x80484ec : jmp    *0x804a014
   0x80484f2 : push   $0x28
   0x80484f7 : jmp    0x804848c
   0x80484fc : jmp    *0x804a018
   0x8048502 : push   $0x30
   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的前三项的特殊含义的说明。

  1. (gdb) b * 0x00123220
  2. Breakpoint 2 at 0x123220: file ../sysdeps/i386/dl-trampoline.S, line 29.
  3. (gdb) c
  4. Continuing.
  5. Breakpoint 2, _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:29
  6. 29 ../sysdeps/i386/dl-trampoline.S: 没有那个文件或目录.
  7. in ../sysdeps/i386/dl-trampoline.S
  8. (gdb) disas 0x00123220
  9. Dump of assembler code for function _dl_runtime_resolve:
  10. => 0x00123220 <+0>: push %eax
  11. 0x00123221 <+1>: push %ecx
  12. 0x00123222 <+2>: push %edx
  13. 0x00123223 <+3>: mov 0x10(%esp),%edx
  14. 0x00123227 <+7>: mov 0xc(%esp),%eax
  15. 0x0012322b <+11>: call 0x11d550 <_dl_fixup>
  16. 0x00123230 <+16>: pop %edx
  17. 0x00123231 <+17>: mov (%esp),%ecx
  18. 0x00123234 <+20>: mov %eax,(%esp)
  19. 0x00123237 <+23>: mov 0x4(%esp),%eax
  20. 0x0012323b <+27>: ret $0xc
  21. End of assembler dump.
我们看到的,_dl_runtime_resolve调用的_dl_fixup,来修改GOT表中的表项,还记的

  1. (gdb) x 0x804a000
  2. 0x804a000 <_GLOBAL_OFFSET_TABLE_+12>: 0x080484a2

    执行完,之后,我们看下
  1. (gdb) x/20x 0x8049FF4
  2. 0x8049ff4 <_GLOBAL_OFFSET_TABLE_>: 0x08049f18 0x0012c8f8 0x00123220 0x0012e4a7 ----这回这个地址就是ml_func的                                                                                   地址
  3. 0x804a004 <_GLOBAL_OFFSET_TABLE_+16>: 0x080484b2 0x0018fb70 0x00147af0 0x00178130
  4. 0x804a014 <_GLOBAL_OFFSET_TABLE_+32>: 0x080484f2 0x00234e10 0x00000000 0x00000000
  5. 0x804a024 : 0x00000000 0x00000000 0x00000000 0x00000000
  6. 0x804a034: 0x00000000 0x00000000 0x00000000 0x00000000
    我们看到GOT发生了变化,第四项内容从原来的0x80484a2变成了,0x0012e4a7,这个地址,就是传说中的ml_func的地址,我们验证下
  1. (gdb) p &ml_func
  2. $1 = (int (*)(int, int)) 0x12e4a7
    Bingo,这就是一个完整的PLT的过程,对_dl_runtime_resolve函数感兴趣的兄弟可以继续深究。


参考文献:
1 程序员的自我修养

阅读(537) | 评论(0) | 转发(0) |
0

上一篇:没有了

下一篇:没有了

给主人留下些什么吧!~~