Chinaunix首页 | 论坛 | 博客

潜心修行bean.blog.chinaunix.net

首页　| 　博文目录　| 　关于我

Bean_lee

  • 博客访问： 3882186
  • 博文数量： 146
  • 博客积分： 3918
  • 博客等级： 少校
  • 技术积分： 8585
  • 用 户 组： 普通用户
  • 注册时间： 2010-10-17 13:52
个人简介

个人微薄： weibo.com/manuscola

文章分类

全部博文（146）

文章存档

2016年（3）

2015年（2）

2014年（5）

2013年（42）

2012年（31）

2011年（58）

2010年（5）

我的朋友
最近访客
推荐博文
相关博文
动态链接库之延迟绑定探究

分类： LINUX

2012-01-03 19:36:16

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

  3. int ml_util_func(int a)
  4. {
  5.     return a + 1;
  6. }
  7. int ml_func(int a, int b)
  8. {
  9.                 int c = b + ml_util_func(a);
  10.                 myglob += c;
  11.                 return b + myglob;
  12. }
  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. }

  21. extern int ml_func(int, int);

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

  27.                 int t = ml_func(argc, argc);
  28.                 sleep(12);
  29.                 return t;
  30. }

  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);

  4. (gdb) disas 0x804849c
  5. Dump of assembler code for function ml_func@plt:
  6.    0x0804849c <+0>:    jmp *0x804a000
  7.    0x080484a2 <+6>:    push $0x0
  8.    0x080484a7 <+11>:   jmp 0x804848c
  9. End of assembler dump.
  10. (gdb) x 0x804a000
  11. 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.
  6. Breakpoint 2, _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:29
  7. 29 ../sysdeps/i386/dl-trampoline.S: 没有那个文件或目录.
  8. in ../sysdeps/i386/dl-trampoline.S
  9. (gdb) disas 0x00123220
  10. Dump of assembler code for function _dl_runtime_resolve:
  11. => 0x00123220 <+0>: push %eax
  12. 0x00123221 <+1>: push %ecx
  13. 0x00123222 <+2>: push %edx
  14. 0x00123223 <+3>: mov 0x10(%esp),%edx
  15. 0x00123227 <+7>: mov 0xc(%esp),%eax
  16. 0x0012322b <+11>: call 0x11d550 <_dl_fixup>
  17. 0x00123230 <+16>: pop %edx
  18. 0x00123231 <+17>: mov (%esp),%ecx
  19. 0x00123234 <+20>: mov %eax,(%esp)
  20. 0x00123237 <+23>: mov 0x4(%esp),%eax
  21. 0x0012323b <+27>: ret $0xc
  22. 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 程序员的自我修养
2 

阅读(8990) | 评论(0) | 转发(5) |
0

上一篇：system函数返回值探究

下一篇：重启系统调用探究

给主人留下些什么吧！~~
关于我们 | 关于IT168 | 联系方式 | 广告合作 | 法律声明 | 免费注册

Copyright 2001-2010 ChinaUnix.net All Rights Reserved 北京皓辰网域网络信息技术有限公司. 版权所有

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6