Solaris学习笔记(3)

最新推荐文章于 2024-08-02 16:11:34 发布

herx1

最新推荐文章于 2024-08-02 16:11:34 发布

阅读量881

点赞数

文章标签： solaris linker list object struct c

作者: Badcoffee
Email: blog.oliver@gmail.com
Blog: http://blog.csdn.net/yayong
2006年3月

很久以前就看过alert7写的那篇 ELF 动态解析符号过程(修订版)，大概是他在学习ELF文件格式时写的吧。OpenSolaris之后，其内核所有代码全世界都可以访问到，于是就有了这篇文章。本文仅用于学习交流目的，因此没有经过严格校对，错误再所难免，如果有勘误或疑问请与我联系。

关键词：Dynamic binding/ld.so/mdb/link map/Solaris

1. 基本概念

Link-Editor - 链接器：即ld(1)，输入一个或多个输入文件(*.o/*.so/*.a)，经过连接和解释数据，输出一个目标文件(*.o/*.so/*.a/可执行文件)。ld通常作为编译环境的一部分来执行。

Runtime Linker - 动态链接器: 即ld.so.1(1), 在运行时刻处理动态的可执行程序和共享库，把可执行程序和共享库绑定在一起创建一个可执行的进程。

Shared objects - 共享对象: 也叫共享库，是动态链接系统的基础。共享对象类似与动态可执行文件，但共享对象没有被指定虚拟内存地址。共享对象可以在系统中多个应用程序共同使用和共享。

Dynamic executables - 动态可执行文件：通常依赖于一个或者多个共享对象。为了产生一个可以执行的进程，一个或者多个共享对象必须绑定在动态可执行文件上。

runtime linker主要负责以下几方面工作:

1.分析可执行文件中包含的动态信息部分(对ELF文件来说就是.dynamic section)来决定该文件运行所需的依赖库；
2.定位和装载这些依赖库，分析这些依赖库所包含的动态信息部分，来决定是否需装载要任何附加的依赖库；
3.对动态库进行必要的重定位，在进程的执行期间绑定这些对象；
4.调用这些依赖库提供的初始化函数(ELF文件来说就是.init section,而且顺序是先执行依赖库的，再执行可执行文件的)；
5.把控制权转交给应用程序；
6.在应用程序执行期间，能被再调用，来执行延后的函数绑定(即动态解析)；
7.在应用程序调用dlopen(3C)打开动态库和用dlsym(3C)绑定这些库的符号时，也要被调用；

2. 测试与验证

写一个最简的测试程序test.c：

#include <stdio.h>
int main(int agrc, char *argv[])
{
       printf ("hello world/n");
       return 0;
}

编译和链接后产生ELF文件：

# cc test.c -o test
# file test
test:           ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped

用mdb反汇编main函数：

# mdb test
> main::dis
main:                           pushl  %ebp
main+1:                         movl   %esp,%ebp
main+3:                         subl   $0x10,%esp
main+6:                         movl   %ebx,-0x8(%ebp)
main+9:                         movl   %esi,-0xc(%ebp)
main+0xc:                       movl   %edi,-0x10(%ebp)
main+0xf:                       pushl  $0x80506ec
main+0x14:                      call   -0x148   <PLT:printf>
main+0x19:                      addl   $0x4,%esp
main+0x1c:                      movl   $0x0,-0x4(%ebp)
main+0x23:                      jmp    +0x5     <main+0x28>
main+0x28:                      movl   -0x4(%ebp),%eax
main+0x2b:                      movl   -0x8(%ebp),%ebx
main+0x2e:                      movl   -0xc(%ebp),%esi
main+0x31:                      movl   -0x10(%ebp),%edi
main+0x34:                      leave
main+0x35:                      ret

可以看到，main+0x14处调用了函数printf，调用前把传递的字符串参数压入栈：

> 0x80506ec/s
0x80506ec:      hello world

“hello world”在ELF文件的.rodata1 section，处于test的代码段：

# /usr/ccs/bin/elfdump -c -N .rodata1 test

Section Header[13]:  sh_name: .rodata1
   sh_addr:      0x80506ec       sh_flags:   [ SHF_ALLOC ]
   sh_size:      0xd             sh_type:    [ SHT_PROGBITS ]
   sh_offset:    0x6ec           sh_entsize: 0
   sh_link:      0               sh_info:    0
   sh_addralign: 0x4

用mdb在main+0x14处设置断点，然后运行程序：

> main+0x14:b
> :r
mdb: stop at main+0x14
mdb: target stopped at:
main+0x14:      call   -0x148   <PLT:printf>

程序在调用printf之前停止，我们计算一下printf的地址：


> main+0x14-0x148=X
               8050544

验证一下，地址0x8050544是否正确：


# /usr/ccs/bin/elfdump -s -N .symtab test | grep printf
     [38]  0x08050544 0x00000000  FUNC GLOB  D    0 UNDEF       printf
# /usr/ccs/bin/elfdump -s -N .dynsym test | grep printf
      [1]  0x08050544 0x00000000  FUNC GLOB  D    0 UNDEF       printf

在test文件的.symtab和.dynsym section都可以找到符号表中包含printf，符号表实际上是一个数组，数组元素定义如下：

typedef struct {
  Elf32_Word st_name;
  Elf32_Addr st_value;
  Elf32_Word st_size;
  unsigned char st_info;
  unsigned char st_other;
  Elf32_Half st_shndx;
} Elf32_Sym;

printf的st_value就是0x08050544，在ELF的可执行文件中，这就是printf的虚存地址，而这恰好就是我们mdb中计算的地址。

我们同样可以用nm(1)命令确认这一点:

# /usr/ccs/bin/nm -x test | grep printf
[Index]   Value      Size    Type  Bind  Other Shndx   Name
......
[38]    |0x08050544|0x00000000|FUNC |GLOB |0    |UNDEF  |printf

printf的st_shndx的值是UNDEF，说明printf未在test中定义。既然程序可以链接通过，那么printf肯定存在于它依赖的共享库中。

test依赖的共享库如下:

# ldd test
       libc.so.1 =>     /lib/libc.so.1
       libm.so.2 =>     /lib/libm.so.2

当一个程序有多个共享库依赖时，runtime linker是按照一定的顺序运行各个库的.init函数的，即前面提到的步骤4，查看顺序用ldd -i：

# ldd -i /usr/bin/cp
       libcmdutils.so.1 =>      /lib/libcmdutils.so.1
       libavl.so.1 =>   /lib/libavl.so.1
       libsec.so.1 =>   /lib/libsec.so.1
       libc.so.1 =>     /lib/libc.so.1
       libm.so.2 =>     /lib/libm.so.2

  init object=/lib/libc.so.1
  init object=/lib/libavl.so.1
  init object=/lib/libcmdutils.so.1
  init object=/lib/libsec.so.1

test依赖的库只有libc(3LIB)和libm(3LIB)，libm是数学库，因此printf一定在libc(3LIB)中。我们知道，在 libc(3LIB)库中，包含了System V, ANSI C, POSIX等多种标准的函数实现。

查看libc.so的符号表中的printf：

# /usr/ccs/bin/nm -x /usr/lib/libc.so | grep  "|printf___FCKpd___13quot;
[Index]   Value      Size    Type  Bind  Other Shndx   Name
......
[7653]  |0x00061f39|0x00000105|FUNC |GLOB |0    |11     |printf

libc.so中printf的st_value是0x00061f39，由于libc.so是一个共享库，因此这个地址只是printf在 libc.so中的偏移量，需要和libc.so的加载地址相加才可以得出真正的虚存地址，而这个地址才是真正的printf函数的代码入口。

libc.so中printf的st_shndx的值为11,当st_shndx是数值是，代表改函数所在的section header的索引号：

# /usr/ccs/bin/elfdump -c /usr/lib/libc.so | grep 11
Section Header[11]:  sh_name: .text
   sh_size:      0x110           sh_type:    [ SHT_SUNW_SIGNATURE ]

ELF文件test中的.symtab和.dynsym都包含了printf，而且st_value都相同，但是我们看到如果strip以后，nm命令没有输出，这是因为test文件中的.symtab section被去除的原因：

# /usr/ccs/bin/strip test
# /usr/ccs/bin/elfdump -s -N .symtab test | grep printf
# /usr/ccs/bin/nm -x test1 | grep printf
# /usr/ccs/bin/elfdump -s -N .dynsym test | grep printf
      [1]  0x08050544 0x00000000  FUNC GLOB  D    0 UNDEF       printf

实际上只有.dynsym才被影射入内存，.dynsym是实现动态链接必须的信息,.symtab根本不会影射入内存。

在test创建的进程中，printf位于地址8050544，用mdb反汇编printf的代码：

> 8050544::dis
PLT:printf:                     jmp    *0x8060714
PLT:printf:                     pushl  $0x18
PLT:printf:                     jmp    -0x4b    <0x8050504>
PLT:_get_exit_frame_monitor:    jmp    *0x8060718
PLT:_get_exit_frame_monitor:    pushl  $0x20
PLT:_get_exit_frame_monitor:    jmp    -0x5b    <0x8050504>
................

可以看到，实际上，printf的代码只有3条指令，显然，这并不是真正printf的实现，而是叫做PLT的其中部分代码。

Global Offset Table - 全局偏移量表：GOT存在于可执行文件的数据段中，用于存放位置无关函数的绝对地址。GOT表中的绝对地址实际上是在运行阶段时，在位置无关函数首次被 runtime linker解析后才确定。在此之前，GOT中的初值主要是为了帮助PLT跳转到runtime linker，把控制权转交给它的动态绑定函数。

其实，.got的初值在test文件中已经定义：

# /usr/ccs/bin/elfdump -c -N .got test

Section Header[14]:  sh_name: .got
   sh_addr:      0x80606fc       sh_flags:   [ SHF_WRITE  SHF_ALLOC ]
   sh_size:      0x20            sh_type:    [ SHT_PROGBITS ]
   sh_offset:    0x6fc           sh_entsize: 0x4
   sh_link:      0               sh_info:    0
   sh_addralign: 0x4

# /usr/ccs/bin/elfdump -G test

Global Offset Table Section:  .got  (8 entries)
ndx     addr      value    reloc              addend   symbol
[00000]  080606fc  0806071c R_386_NONE         00000000
[00001]  08060700  00000000 R_386_NONE         00000000
[00002]  08060704  00000000 R_386_NONE         00000000
[00003]  08060708  0805051a R_386_JMP_SLOT     00000000 atexit
[00004]  0806070c  0805052a R_386_JMP_SLOT     00000000 __fpstart
[00005]  08060710  0805053a R_386_JMP_SLOT     00000000 exit
[00006]  08060714  0805054a R_386_JMP_SLOT     00000000 printf
[00007]  08060718  0805055a R_386_JMP_SLOT     00000000 _get_exit_frame_monitor

可以看到，在ELF文件中的GOT共有8个表项:

    GOT[0]是保留项，被初始化为.dynamic section的起始地址。
    GOT[1]和GOT[2]初值为0，在装入内存后初始化。
    GOT[3]-GOT[7]，被初始化成了对应符号的在PLT中第2条指令的地址。

GOT的结束地址也可以根据section header中的sh_size计算出来：


> 0x80606fc+20=X
               806071c

而test运行到main+0x14断点处，查看GOT：

> 0x80606fc,9/naX
0x80606fc:
0x80606fc:      806071c
0x8060700:      d17fd900
0x8060704:      d17cb260
0x8060708:      d1710814
0x806070c:      d1701e51
0x8060710:      805053a
0x8060714:      805054a
0x8060718:      805055a
0x806071c:      1

可以看到，GOT的内容和ELF文件定义的初始值相比，有了一些变化：

> 0x80606fc,9/nap
0x80606fc:
0x80606fc:      0x806071c                    --->未改变，.dynamic section的起始地址
0x8060700:      0xd17fd900                   --->改变，Rt_map首地址，也是link_map首地址
0x8060704:      ld.so.1`elf_rtbndr           --->改变，Runtime linker的入口
0x8060708:      libc.so.1`atexit             --->改变，已经被ld.so解析成绝对地址
0x806070c:      libc.so.1`_fpstart           --->改变，已经被ld.so解析成绝对地址
0x8060710:      PLT:exit                     --->未改变，还未解析，指向PLT:exit的第2条指令
0x8060714:      PLT:printf                   --->未改变，还未解析，指向PLT:printf的第2条指令
0x8060718:      PLT:_get_exit_frame_monitor  --->未改变，还未解析，指向PLT:_get_exit_frame_monitor的第2条指令
0x806071c:      1

在此时，runtim linker把link map和自己的入口函数地址填入了GOT[1]和GOT[2]中，并且atexit和_fpstart已经被解析成绝对地址。这是因为每个可执行文件的实际入口是_start例程，这个例程执行中会调用atexit和_fpstart，然后才调用main函数：

> _start::dis
_start:                         pushl  $0x0
_start+2:                       pushl  $0x0
_start+4:                       movl   %esp,%ebp
_start+6:                       pushl  %edx
_start+7:                       movl   $0x806071c,%eax
_start+0xc:                     testl  %eax,%eax
_start+0xe:                     je     +0x7     <_start+0x15>
_start+0x10:                    call   -0x64    <PLT:atexit>
_start+0x15:                    pushl  $0x80506cc
_start+0x1a:                    call   -0x6e    <PLT:atexit>
_start+0x1f:                    leal   0x80607f4,%eax
_start+0x25:                    movl   (%eax),%eax
_start+0x27:                    testl  %eax,%eax
_start+0x29:                    je     +0x17    <_start+0x40>
_start+0x2b:                    leal   0x80607f8,%eax
_start+0x31:                    movl   (%eax),%eax
_start+0x33:                    testl  %eax,%eax
_start+0x35:                    je     +0xb     <_start+0x40>
_start+0x37:                    pushl  %eax
_start+0x38:                    call   -0x8c    <PLT:atexit>
_start+0x3d:                    addl   $0x4,%esp
_start+0x40:                    movl   0x8(%ebp),%eax
_start+0x43:                    movl   0x80607d4,%edx
_start+0x49:                    testl  %edx,%edx
_start+0x4b:                    jne    +0xc     <_start+0x57>
_start+0x4d:                    leal   0x10(%ebp,%eax,4),%edx
_start+0x51:                    movl   %edx,0x80607d4
_start+0x57:                    andl   $0xfffffff0,%esp
_start+0x5a:                    pushl  %edx
_start+0x5b:                    leal   0xc(%ebp),%edx
_start+0x5e:                    movl   %edx,0x80607f0
_start+0x64:                    pushl  %edx
_start+0x65:                    pushl  %eax
_start+0x66:                    call   -0xaa    <PLT:__fpstart>
_start+0x6b:                    call   +0x29    <__fsr>
_start+0x70:                    call   +0xd8    <_init>
_start+0x75:                    call   +0x9b    <main>
_start+0x7a:                    addl   $0xc,%esp
_start+0x7d:                    pushl  %eax
_start+0x7e:                    call   -0xb2    <PLT:exit>
_start+0x83:                    pushl  $0x0
_start+0x85:                    movl   $0x1,%eax
_start+0x8a:                    lcall  $0x7,$0x0
_start+0x91:                    hlt

Procedure Linkage Table - 过程链接表：PLT存在于每个ELF可执行文件的代码段，它和可执行文件的数据段中的GOT来一起决定位置无关函数的绝对地址。首先，第一次调用位置无关函数时，会进入相应函数的PLT入口，PLT的指令会从GOT中读出默认地址，该地址正好是PLT0的入口地址，PLT0会把控制权交给runtime linker，由runtime linker解析出该函数的绝对地址，然后将这个绝对地址存入GOT，然后，该函数将被调用。然后，当再次调用该函数时，由于GOT中已经存放了该函数入口的绝对地址，因此PLT对应的指令会直接跳转到函数绝对地址，而不会再由runtime linker解析。

PLT的一般格式如下：

.PLT0:pushl got_plus_4
      jmp *got_plus_8
      nop; nop
      nop; nop
.PLT1:jmp *name1_in_GOT
      pushl $offset@PC
      jmp .PLT0@PC ...
.PLT2:jmp *name2_in_GOT
      push $offset
      jmp .PLT0@PC
.PLT2:jmp *name3_in_GOT
      push $offset
      jmp .PLT0@PC

可以通过elfdump来实际查看test文件验证一下:

# /usr/ccs/bin/elfdump -c -N .plt test

Section Header[8]:  sh_name: .plt
   sh_addr:      0x8050504       sh_flags:   [ SHF_ALLOC  SHF_EXECINSTR ]
   sh_size:      0x60            sh_type:    [ SHT_PROGBITS ]
   sh_offset:    0x504           sh_entsize: 0x10
   sh_link:      0               sh_info:    0
   sh_addralign: 0x4

这样，PLT的结束地址也可以计算出来:

> 0x8050504+0x60=X
               8050564

根据.plt的起始和结束地址可以反汇编：

> 0x8050504::dis -a -n 13
8050504                         pushl  0x8060700             ---->pushl got_plus_4，指向Rt_map地址
805050a                         jmp    *0x8060704            ---->jmp *got_plus_8，跳转到Runtime linker的入口
8050510                         addb   %al,(%eax)
8050512                         addb   %al,(%eax)
8050514                         jmp    *0x8060708
805051a                         pushl  $0x0
805051f                         jmp    -0x1b    <0x8050504>
8050524                         jmp    *0x806070c
805052a                         pushl  $0x8
805052f                         jmp    -0x2b    <0x8050504>
8050534                         jmp    *0x8060710
805053a                         pushl  $0x10
805053f                         jmp    -0x3b    <0x8050504>
8050544                         jmp    *0x8060714            ---->跳转到0x805054a，即下一条指令
805054a                         pushl  $0x18
805054f                         jmp    -0x4b    <0x8050504>
8050554                         jmp    *0x8060718
805055a                         pushl  $0x20
805055f                         jmp    -0x5b    <0x8050504>
8050564                         addb   %al,(%eax)

或者包含符号信息：

> 0x8050504::dis -n 13
0x8050504:                      pushl  0x8060700
0x805050a:                      jmp    *0x8060704
0x8050510:                      addb   %al,(%eax)
0x8050512:                      addb   %al,(%eax)
PLT=libc.so.1`atexit:           jmp    *0x8060708
PLT=libc.so.1`atexit:           pushl  $0x0
PLT=libc.so.1`atexit:           jmp    -0x1b    <0x8050504>
PLT=libc.so.1`_fpstart:         jmp    *0x806070c
PLT=libc.so.1`_fpstart:         pushl  $0x8
PLT=libc.so.1`_fpstart:         jmp    -0x2b    <0x8050504>
PLT:exit:                       jmp    *0x8060710
PLT:exit:                       pushl  $0x10
PLT:exit:                       jmp    -0x3b    <0x8050504>
PLT:printf:                     jmp    *0x8060714
PLT:printf:                     pushl  $0x18
PLT:printf:                     jmp    -0x4b    <0x8050504>
PLT:_get_exit_frame_monitor:    jmp    *0x8060718
PLT:_get_exit_frame_monitor:    pushl  $0x20
PLT:_get_exit_frame_monitor:    jmp    -0x5b    <0x8050504>
0x8050564:                      addb   %al,(%eax)

在main+0x14处，继续单步运行：

> :s
mdb: target stopped at:
PLT:printf:     jmp    *0x8060714

查看0x8060714即printf在GOT中的内容，其实就是PLT:printf中下一条push指令：


> *0x8060714=X
               805054a
> *0x8060714::dis -n 1
PLT:printf:                     pushl  $0x18
PLT:printf:                     jmp    -0x4b    <0x8050504>

继续单部执行，马上就要把0x18压入栈，这个0x18就是printf在重定位表中的偏移量:

# /usr/ccs/bin/elfdump -c -N .rel.plt test

Section Header[7]:  sh_name: .rel.plt
   sh_addr:      0x80504dc       sh_flags:   [ SHF_ALLOC  SHF_INFO_LINK ]
   sh_size:      0x28            sh_type:    [ SHT_REL ]
   sh_offset:    0x4dc           sh_entsize: 0x8
   sh_link:      3               sh_info:    8
   sh_addralign: 0x4

# /usr/ccs/bin/elfdump -d test

Dynamic Section:  .dynamic
    index  tag               value
      [0]  NEEDED           0x111             libc.so.1
      [1]  INIT             0x80506b0
      [2]  FINI             0x80506cc
      [3]  HASH             0x80500e8
      [4]  STRTAB           0x805036c
      [5]  STRSZ            0x137
      [6]  SYMTAB           0x80501cc
      [7]  SYMENT           0x10
      [8]  CHECKSUM         0x5a2b
      [9]  VERNEED          0x80504a4
     [10]  VERNEEDNUM       0x1
     [11]  PLTRELSZ         0x28
     [12]  PLTREL           0x11
     [13]  JMPREL           0x80504dc  ---> 重定位表.rel.plt的基地址
     [14]  REL              0x80504d4
     [15]  RELSZ            0x30
     [16]  RELENT           0x8
     [17]  DEBUG            0
     [18]  FEATURE_1        0x1               [ PARINIT ]
     [19]  FLAGS            0                 0
     [20]  FLAGS_1          0                 0
     [21]  PLTGOT           0x80606fc

直接查看重定位表内容：

# /usr/ccs/bin/elfdump -r  test

Relocation Section:  .rel.data
       type                          offset             section        with respect to
       R_386_32                   0x80607f8             .rel.data      __1cG__CrunMdo_exit_code6F_v_

Relocation Section:  .rel.plt
       type                          offset             section        with respect to
       R_386_JMP_SLOT             0x8060708             .rel.plt       atexit
       R_386_JMP_SLOT             0x806070c             .rel.plt       __fpstart
       R_386_JMP_SLOT             0x8060710             .rel.plt       exit
       R_386_JMP_SLOT             0x8060714             .rel.plt       printf
       R_386_JMP_SLOT             0x8060718             .rel.plt       _get_exit_frame_monitor

其中，printf是4项，而在32位x86平台上，重定位表的每项的长度为8字节，定义如下：

typedef struct {
  Elf32_Addr r_offset;
  Elf32_Word r_info;
} Elf32_Rel;

因此，printf在重定位表中偏移量=(4-1)*8=24，即16进制的0x18。

用mdb查看实际内存中的重定位表：

> 0x80504dc,a/nap
0x80504dc:
0x80504dc:      0x8060708
0x80504e0:      0xf07
0x80504e4:      0x806070c
0x80504e8:      0x1007
0x80504ec:      0x8060710
0x80504f0:      0x1207
0x80504f4:      0x8060714
0x80504f8:      0x107
0x80504fc:      0x8060718
0x8050500:      0x1307

可以看到，printf的r_offset是0x8060714，r_info是0x107。对照前面的GOT各项的地址，可以发现，0x8060714 就是GOT[7]的地址。


> :s
mdb: target stopped at:
PLT:printf:     pushl  $0x18

继续单步执行:

> :s
mdb: target stopped at:
PLT:printf:     jmp    -0x4b    <0x8050504>

地址0x8050504就是PLT0的地址：


> :s
mdb: target stopped at:
0x8050504:      pushl  0x8060700

0x8060700就是GOT[1]，存储的就是Rt_map的首地址，相当于把Rt_map的首地址压栈：


> :s
mdb: target stopped at:
0x805050a:      jmp    *0x8060704

0x8060704就是GOT[2]，存储着runtime linker - ld.so的入口地址：

> :s
mdb: target stopped at:
ld.so.1`elf_rtbndr:     pushl  %ebp

可以看到，这样控制权就由PLT这样转换到runtime linker了，显然，下面将进入runtime link editor来动态绑定了，我们查看目前栈的状态：

> <esp,10/nap
0x804734c:
0x804734c:      0xd17fd900 ----> Rt_map的首地址
0x8047350:      0x18       ----> printf对应项重定位表中的偏移量
0x8047354:      main+0x19  ----> printf返回后应跳转的地址
0x8047358:      0x80506ec
0x804735c:      0x8047460
0x8047360:      0x8047354
0x8047364:      0xd17fb840
0x8047368:      0x8047460
0x804736c:      0x804738c
0x8047370:      _start+0x7a
0x8047374:      1
0x8047378:      0x8047398
0x804737c:      0x80473a0
0x8047380:      _start+0x1f
0x8047384:      _fini
0x8047388:      ld.so.1`atexit_fini

查看ld.so.1`elf_rtbndr函数的定义，这部分是平台相关的，我们只关心32bit x86部分的实现：

link:http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/rtld/i386/boot_elf.s

   288 #if defined(lint)
   289
   290 extern unsigned long    elf_bndr(Rt_map *, unsigned long, caddr_t);
   291
   292 void
   293 elf_rtbndr(Rt_map * lmp, unsigned long reloc, caddr_t pc)
   294 {
   295     (void) elf_bndr(lmp, reloc, pc);
   296 }
   297
   298 #else
   299     .globl    elf_bndr
   300     .globl    elf_rtbndr
   301     .weak    _elf_rtbndr
   302     _elf_rtbndr = elf_rtbndr    / Make dbx happy
   303     .type   elf_rtbndr,@function
   304     .align    4
   305
   306 elf_rtbndr:
   307     pushl    %ebp
   308     movl    %esp, %ebp
   309     pushl    %eax
   310     pushl    %ecx
   311     pushl    %edx
   312     pushl    12(%ebp)        / push pc
   313     pushl    8(%ebp)            / push reloc
   314     pushl    4(%ebp)            / push *lmp
   315     call    elf_bndr@PLT        / call the C binder code
   316     addl    $12, %esp        / pop args
   317     movl    %eax, 8(%ebp)        / store final destination
   318     popl    %edx
   319     popl    %ecx
   320     popl    %eax
   321     movl    %ebp, %esp
   322     popl    %ebp
   323     addl    $4,%esp            / pop args
   324     ret                / invoke resolved function
   325     .size     elf_rtbndr, .-elf_rtbndr
   326 #endif

315行调用的elf_bndr是平台相关代码，函数原型如下：

   290 extern unsigned long    elf_bndr(Rt_map *, unsigned long, caddr_t);

因此在elf_rtbndr的312-314这几行，实际上是为调用elf_bndr做传递参数的准备:

   312     pushl    12(%ebp)        / push返回地址 main+0x19
   313     pushl    8(%ebp)         / push重定位表的对应printf项的偏移量 0x18
   314     pushl    4(%ebp)         / push Rt_map的首地址，0xd17fd900

根据32位x86的ABI，压栈顺序是从右到左，正好吻合elf_bndr的参数顺序和类型定义。

通过在elf_bndr函数调用前设置断点来验证一下：

> ld.so.1`elf_rtbndr::dis
ld.so.1`elf_rtbndr:             pushl  %ebp
ld.so.1`elf_rtbndr+1:           movl   %esp,%ebp
ld.so.1`elf_rtbndr+3:           pushl  %eax
ld.so.1`elf_rtbndr+4:           pushl  %ecx
ld.so.1`elf_rtbndr+5:           pushl  %edx
ld.so.1`elf_rtbndr+6:           pushl  0xc(%ebp)
ld.so.1`elf_rtbndr+9:           pushl  0x8(%ebp)
ld.so.1`elf_rtbndr+0xc:         pushl  0x4(%ebp)
ld.so.1`elf_rtbndr+0xf:         call   +0x14c5d <ld.so.1`elf_bndr>
ld.so.1`elf_rtbndr+0x14:        addl   $0xc,%esp
ld.so.1`elf_rtbndr+0x17:        movl   %eax,0x8(%ebp)
ld.so.1`elf_rtbndr+0x1a:        popl   %edx
ld.so.1`elf_rtbndr+0x1b:        popl   %ecx
ld.so.1`elf_rtbndr+0x1c:        popl   %eax
ld.so.1`elf_rtbndr+0x1d:        movl   %ebp,%esp
ld.so.1`elf_rtbndr+0x1f:        popl   %ebp
ld.so.1`elf_rtbndr+0x20:        addl   $0x4,%esp
ld.so.1`elf_rtbndr+0x23:        ret
> ld.so.1`elf_rtbndr+0xf:b
> :c
mdb: stop at ld.so.1`elf_rtbndr+0xf
mdb: target stopped at:
ld.so.1`elf_rtbndr+0xf: call   +0x14c5d <ld.so.1`elf_bndr>

下面检查ld.so.1`elf_bndr调用前栈的状况，可以看到，3个参数已经按顺序压入栈中：

> <esp,10/nap
0x8047330:
0x8047330:      0xd17fd900
0x8047334:      0x18
0x8047338:      main+0x19
0x804733c:      3
0x8047340:      libc.so.1`_sse_hw
0x8047344:      libc.so.1`__flt_rounds
0x8047348:      0x804736c
0x804734c:      0xd17fd900
0x8047350:      0x18
0x8047354:      main+0x19
0x8047358:      0x80506ec
0x804735c:      0x8047460
0x8047360:      0x8047354
0x8047364:      0xd17fb840
0x8047368:      0x8047460
0x804736c:      0x804738c
>

elf_rtbndr会返回我们需要的printf在libc.so中的绝对地址吗？

用mdb在ld.so.1`elf_rtbndr返回处设置断点，继续执行：

> ld.so.1`elf_rtbndr+0x14:b
> :c
mdb: stop at ld.so.1`elf_rtbndr+0x14
mdb: target stopped at:
ld.so.1`elf_rtbndr+0x14:addl   $0xc,%esp

检查一下函数返回值，它应该存在rax的寄存器中：

> <eax=X
               d1741f39

显然，d1741f39就是printf的绝对地址，它处于libc.so中：

> d1741f39::dis -w
libc.so.1`printf:               pushl  %ebp
libc.so.1`printf+1:             movl   %esp,%ebp
libc.so.1`printf+3:             subl   $0x10,%esp
libc.so.1`printf+6:             andl   $0xfffffff0,%esp
libc.so.1`printf+9:             pushl  %ebx
libc.so.1`printf+0xa:           pushl  %esi
libc.so.1`printf+0xb:           pushl  %edi
libc.so.1`printf+0xc:           call   +0x5     <libc.so.1`printf+0x11>
libc.so.1`printf+0x11:          popl   %ebx
libc.so.1`printf+0x12:          addl   $0x6d0b6,%ebx
libc.so.1`printf+0x18:          movl   0x244(%ebx),%esi

此时此刻，GOT中的printf的对应项GOT[7]，即0x8060714地址处，已经被ld.so修改成printf的绝对地址：

> 0x80606fc,9/nap
0x80606fc:
0x80606fc:      0x806071c
0x8060700:      0xd17fd900
0x8060704:      ld.so.1`elf_rtbndr
0x8060708:      libc.so.1`atexit
0x806070c:      libc.so.1`_fpstart
0x8060710:      PLT:exit
0x8060714:      libc.so.1`printf
0x8060718:      PLT:_get_exit_frame_monitor
0x806071c:      1
>

printf被成功解析后，ld.so修改了GOT[7]，接着就应该把控制权转到libc的printf函数了。显然，在 ld.so.1`elf_rtbndr+0x17处的指令将会把eax寄存器中的printf的绝对函数地址存入栈中：

> ld.so.1`elf_rtbndr+0x17:b
> :c
mdb: stop at ld.so.1`elf_rtbndr+0x17
mdb: target stopped at:
ld.so.1`elf_rtbndr+0x17:movl   %eax,0x8(%ebp)

此时栈中还没有printf的地址：

> <esp,10/nap
0x80473cc:
0x80473cc:      3
0x80473d0:      libc.so.1`_sse_hw
0x80473d4:      libc.so.1`__flt_rounds
0x80473d8:      0x80473fc
0x80473dc:      0xd17fd900
0x80473e0:      0x18
0x80473e4:      main+0x19
0x80473e8:      0x80506ec
0x80473ec:      0x80474f4
0x80473f0:      0x80473e8
0x80473f4:      0xd17fb840
0x80473f8:      0x80474f4
0x80473fc:      0x8047420
0x8047400:      _start+0x7a
0x8047404:      1
0x8047408:      0x804742c

单步执行后，再观察栈，会发现，printf已经存入栈：

> :s
mdb: target stopped at:
ld.so.1`elf_rtbndr+0x1a:popl   %edx
> <esp,10/nap
0x80473cc:
0x80473cc:      3
0x80473d0:      libc.so.1`_sse_hw
0x80473d4:      libc.so.1`__flt_rounds
0x80473d8:      0x80473fc
0x80473dc:      0xd17fd900
0x80473e0:      libc.so.1`printf
0x80473e4:      main+0x19
0x80473e8:      0x80506ec
0x80473ec:      0x80474f4
0x80473f0:      0x80473e8
0x80473f4:      0xd17fb840
0x80473f8:      0x80474f4
0x80473fc:      0x8047420
0x8047400:      _start+0x7a
0x8047404:      1
0x8047408:      0x804742c

在ld.so.1`elf_rtbndr返回的前一刻，printf恰好成为ld.so.1`elf_rtbndr的返回地址：

> :s
mdb: target stopped at:
ld.so.1`elf_rtbndr+0x23:ret
> <esp,10/nap
0x8047350:
0x8047350:      libc.so.1`printf
0x8047354:      main+0x19
0x8047358:      0x80506ec
0x804735c:      0x8047460
0x8047360:      0x8047354
0x8047364:      0xd17fb840
0x8047368:      0x8047460
0x804736c:      0x804738c
0x8047370:      _start+0x7a
0x8047374:      1
0x8047378:      0x8047398
0x804737c:      0x80473a0
0x8047380:      _start+0x1f
0x8047384:      _fini
0x8047388:      ld.so.1`atexit_fini
0x804738c:      0

这样，控制权就由ld.so到了我们要调用的函数 - printf:

> :s
mdb: target stopped at:
libc.so.1`printf:       pushl  %ebp

至此，一个完整的动态绑定过程结束，此时可以再次反汇编我们的main函数：

> main::dis
main:                           pushl  %ebp
main+1:                         movl   %esp,%ebp
main+3:                         subl   $0x10,%esp
main+6:                         movl   %ebx,-0x8(%ebp)
main+9:                         movl   %esi,-0xc(%ebp)
main+0xc:                       movl   %edi,-0x10(%ebp)
main+0xf:                       pushl  $0x80506ec
main+0x14:                      call   -0x148   <PLT=libc.so.1`printf>
main+0x19:                      addl   $0x4,%esp
main+0x1c:                      movl   $0x0,-0x4(%ebp)
main+0x23:                      jmp    +0x5     <main+0x28>
main+0x28:                      movl   -0x4(%ebp),%eax
main+0x2b:                      movl   -0x8(%ebp),%ebx
main+0x2e:                      movl   -0xc(%ebp),%esi
main+0x31:                      movl   -0x10(%ebp),%edi
main+0x34:                      leave
main+0x35:                      ret
>

可以看到，由于GOT[7]已经存储了printf的绝对地址，因此，反汇编结果发生了变化。

进程第一次调用printf的动态解析的过程如下：


   main
    |
    V
PLT:printf的第1条指令<---GOT[7]指向的地址
    |                         |
    V                         |
PLT:printf的第2条指令<---------+
    |
    V
PLT:printf的第3条指令
    |
    V
PLT0
ld.so.1`elf_rtbndr
    |
    V
libc.so.1`printf

如果该进程再次调用printf：


 main
   |
   V
PLT:printf的第1条指令<---GOT[7]指向的地址
   |                      |
   V                      |
libc.so.1`printf<---------+

3. elf_bndr函数

elf_rtbndr在32bit x86平台的源代码的位置在：
link:http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/rtld/i386/i386_elf.c

要实现动态绑定，elf_bndr应至少完成如下工作：

3.1 确定要绑定的符号

下面部分elf_bndr的代码就是根据重定位表来确定要绑定的符号：

   231     /*
   232      * Use relocation entry to get symbol table entry and symbol name.
   233      */
   234     addr = (ulong_t)JMPREL(lmp);
   235     rptr = (Rel *)(addr + reloff);
   236     rsymndx = ELF_R_SYM(rptr->r_info);
   237     sym = (Sym *)((ulong_t)SYMTAB(lmp) + (rsymndx * SYMENT(lmp)));
   238     name = (char *)(STRTAB(lmp) + sym->st_name);
   239

JMPREL，SYMTAB，SYMENT，STRTAB这些宏都能从函数第1个入口参数lmp指针，即Rt_map指针中得到下面elfdump中看到的值：

# /usr/ccs/bin/elfdump -d test

Dynamic Section:  .dynamic
    index  tag               value
      [0]  NEEDED           0x111             libc.so.1
      [1]  INIT             0x80506b0
      [2]  FINI             0x80506cc
      [3]  HASH             0x80500e8
      [4]  STRTAB           0x805036c                     --->STRTAB(lmp)的值，字符串表基地址                    
      [5]  STRSZ            0x137
      [6]  SYMTAB           0x80501cc                     --->SYMTAB(lmp)的值，符号表基地址
      [7]  SYMENT           0x10                          --->SYMENT(lmp)的值，符号表元素的长度
      [8]  CHECKSUM         0x5a2b
      [9]  VERNEED          0x80504a4
     [10]  VERNEEDNUM       0x1
     [11]  PLTRELSZ         0x28
     [12]  PLTREL           0x11
     [13]  JMPREL           0x80504dc                     --->JMPREL(lmp)的值，重定位表基地址
     [14]  REL              0x80504d4
     [15]  RELSZ            0x30
     [16]  RELENT           0x8
     [17]  DEBUG            0
     [18]  FEATURE_1        0x1               [ PARINIT ]
     [19]  FLAGS            0                 0
     [20]  FLAGS_1          0                 0
     [21]  PLTGOT           0x80606fc

因此，addr的值就是0x80504dc，它实际上是test进程的重定位表的地址。

reloff是第二个参数，在前面查找printf的过程中，我们知道它的值为0x18，因此rptr的值为：

rptr = addr + reloff = 0x80504dc + 0x18 = 80504f4

前面已经用mdb查看实际内存中的重定位表的内容：

# mdb test
> 0x80504dc,a/nap
0x80504dc:
0x80504dc:      0x8060708
0x80504e0:      0xf07
0x80504e4:      0x806070c
0x80504e8:      0x1007
0x80504ec:      0x8060710
0x80504f0:      0x1207
0x80504f4:      0x8060714
0x80504f8:      0x107
0x80504fc:      0x8060718
0x8050500:      0x1307

因此rptr->r_offset=0x8060714，rptr->r_info=0x107，实际上这个rptr就指向 printf在重定位表中的相应项，而rptr->r_offset就对应着printf在GOT中的的地址，即GOT[7]地址。

ELF_R_SYM这个宏实际上是向右位移8位，因此rsymndx的值实际上是：

rsymndx = ELF_R_SYM(rptr->r_info)= 0x107 << 8 = 1

sym就是printf的符号表中的记录：

sym = 0x80501cc + (1 * 0x10) = 0x80501dc

因此name的地址是，它指向printf字符串：

name = 0x805036c + 1 = 0x805036d


# mdb test
> 80501dc,2/nap
0x80501dc:
0x80501dc:      1           ---> sym->st_name
0x80501e0:      PLT:printf  ---> sym->st_value
> 0x805036d/s
0x805036d:      printf      ---> name的值
>

可见，根据给定符号对应的重定位表的偏移量，就可以找到该符号的符号表的记录，进而确定其名字字符串。

3.2 遍历所有依赖库的符号表查找给定符号

   244     llmp = LIST(lmp)->lm_tail;
   245
   246     /*
   247      * Find definition for symbol.
   248      */
   249     sl.sl_name = name;
   250     sl.sl_cmap = lmp;
   251     sl.sl_imap = LIST(lmp)->lm_head;
   252     sl.sl_hash = 0;
   253     sl.sl_rsymndx = rsymndx;
   254     sl.sl_flags = LKUP_DEFT;
   255
   256     if ((nsym = lookup_sym(&sl, &nlmp, &binfo)) == 0) {
   257         eprintf(ERR_FATAL, MSG_INTL(MSG_REL_NOSYM), NAME(lmp),
   258             demangle(name));
   259         rtldexit(LIST(lmp), 1);
   260     }
   261

在256行的lookup_sym函数会根据传入的符号名和link map返回共享库中对应的符号表记录的指针nsym，&nlmp, &binfo是另外的两个返回值。因此，真正确定符号位置的关键参数就是sl参数了,其定义如下：

link:http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/include/rtld.h


   775 typedef struct {
   776     const char    *sl_name;    /* symbol name */
   777     Rt_map        *sl_cmap;    /* callers link-map */
   778     Rt_map        *sl_imap;    /* initial link-map to search */
   779     ulong_t        sl_hash;    /* symbol hash value */
   780     ulong_t        sl_rsymndx;    /* referencing reloc symndx */
   781     uint_t        sl_flags;    /* lookup flags */
   782 } Slookup;
   783

可以看到，sl中包含的信息主要有3类：

符号相关的：*sl_name,sl_hash,sl_rsymndx，唯一地确定符号，sl_hash将用于符号查找 linkmap: *sl_cmap, *sl_imap, 维护着依赖库加载、ld.so控制信息搜索控制标志: sl_flags，此标志直接影响下级调用的code path

要确定一个给定符号在哪一个依赖库，以及其在共享库的绝对地址，link map起着关键的作用，下面是Rt_map定义：

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/include/rtld.h:

   64 typedef struct rt_map    Rt_map;

   459 struct rt_map {
   460     /*
   461      * BEGIN: Exposed to rtld_db - don't move, don't delete
   462      */
   463     Link_map    rt_public;    /* public data */
   ..................................................................................
   485     struct fct    *rt_fct;    /* file class table for this object */
   486     Sym        *(*rt_symintp)(); /* link map symbol interpreter */
   487     void        *rt_priv;    /* private data, object type specific */
   488     Lm_list        *rt_list;    /* link map list we belong to */
   ..................................................................................
   523 };

Rt_map的起始地址处定义了一个结构Link_map，它的定义如下：

   422 typedef struct link_map    Link_map;

   422 typedef struct link_map    Link_map;
   423
   424 struct link_map {
   425     unsigned long    l_addr;        /* address at which object is mapped */
   426     char         *l_name;    /* full name of loaded object */
   427 #ifdef _LP64
   428     Elf64_Dyn    *l_ld;        /* dynamic structure of object */
   429 #else
   430     Elf32_Dyn    *l_ld;        /* dynamic structure of object */
   431 #endif
   432     Link_map    *l_next;    /* next link object */
   433     Link_map    *l_prev;    /* previous link object */
   434     char        *l_refname;    /* filters reference name */
   435 };

可以看到实际上多个Rt_map是可以通过双向链表链接起来。

下面用mdb来查看正在运行着的test的Rt_map,0xd17fd900就是解析printf时传递给elf_bndr的首地址:

> 0xd17fd900,20/nap
0xd17fd900:
0xd17fd900:     0x8050000
0xd17fd904:     0x8047ff5
0xd17fd908:     0x806071c
0xd17fd90c:     0xd17fdd40
0xd17fd910:     0
0xd17fd914:     0
0xd17fd918:     0xd17fdbe8
0xd17fd91c:     0x8050000
0xd17fd920:     0x10820
0xd17fd924:     0x10820
0xd17fd928:     0x20421605
0xd17fd92c:     0x602
0xd17fd930:     0
0xd17fd934:     0xd17fdb78
0xd17fd938:     0
0xd17fd93c:     0
0xd17fd940:     0
0xd17fd944:     0
0xd17fd948:     0
0xd17fd94c:     0xd16d00d8
0xd17fd950:     0
0xd17fd954:     0
0xd17fd958:     0
0xd17fd95c:     0x80506f9
0xd17fd960:     ld.so.1`elf_fct
0xd17fd964:     ld.so.1`elf_find_sym
0xd17fd968:     0xd17fda00
0xd17fd96c:     ld.so.1`lml_main
0xd17fd970:     0xffffffff
0xd17fd974:     0
0xd17fd978:     0
0xd17fd97c:     0x1901

Rt_map结构的成员rt_fct是指向struct fct结构的指针，struct fct结构定义如下：


    71 typedef struct fct {
    72     int    (*fct_are_u_this)(Rej_desc *);    /* determine type of object */
    73     ulong_t    (*fct_entry_pt)(void);        /* get entry point */
    74     Rt_map    *(*fct_map_so)(Lm_list *, Aliste, const char *, const char *,
    75             int);            /* map in a shared object */
    76     void    (*fct_unmap_so)(Rt_map *);    /* unmap a shared object */
    77     int    (*fct_needed)(Lm_list *, Aliste, Rt_map *);
    78                         /* determine needed objects */
    79     Sym    *(*fct_lookup_sym)(Slookup *, Rt_map **, uint_t *);
    80                         /* initialize symbol lookup */
    81     int    (*fct_reloc)(Rt_map *, uint_t);    /* relocate shared object */
    82     Pnode    *fct_dflt_dirs;            /* list of default dirs to */
    83                         /*    search */
    84     Pnode    *fct_secure_dirs;        /* list of secure dirs to */
    85                         /*    search (set[ug]id) */
    86     Pnode    *(*fct_fix_name)(const char *, Rt_map *, uint_t);
    87                         /* transpose name */
    88     char    *(*fct_get_so)(const char *, const char *);
    89                         /* get shared object */
    90     void    (*fct_dladdr)(ulong_t, Rt_map *, Dl_info *, void **, int);
    91                         /* get symbolic address */
    92     Sym    *(*fct_dlsym)(Grp_hdl *, Slookup *, Rt_map **, uint_t *);
    93                         /* process dlsym request */
    94     int    (*fct_verify_vers)(const char *, Rt_map *, Rt_map *);
    95                         /* verify versioning (ELF) */
    96     int    (*fct_set_prot)(Rt_map *, int);
    97                         /* set protection */
    98 } Fct;

可以看到，这个结构中抽象出了一个二进制对象所有相关的操作函数表，根据二进制对象的类型，它可以实际动态绑定函数到不同类型的二进制文件操作函数上，这种实现方式充分体现了操作系统中面向对象设计思想，这使得ld.so扩展新的可执行文件格式的支持变得相当容易。

ELF文件和a.out文件格式的相关代码分别如下，仅供参考：

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/rtld/common/elf.c http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/sgs/rtld/common/a.out.c

用mdb检查test进程的操作函数，可以看到，由于test的类型是ELF文件，因此elf.c定义的函数表绑定到了rt_fct上：

> ld.so.1`elf_fct,10/nap
ld.so.1`elf_fct:
ld.so.1`elf_fct:
ld.so.1`elf_fct:ld.so.1`elf_are_u
ld.so.1`elf_fct+4:              ld.so.1`elf_entry_pt
ld.so.1`elf_fct+8:              ld.so.1`elf_map_so
ld.so.1`elf_fct+0xc:            ld.so.1`elf_unmap_so
ld.so.1`elf_fct+0x10:           ld.so.1`elf_needed
ld.so.1`elf_fct+0x14:           ld.so.1`lookup_sym
ld.so.1`elf_fct+0x18:           ld.so.1`elf_reloc
ld.so.1`elf_fct+0x1c:           ld.so.1`elf_dflt_dirs
ld.so.1`elf_fct+0x20:           ld.so.1`elf_secure_dirs
ld.so.1`elf_fct+0x24:           ld.so.1`elf_fix_name
ld.so.1`elf_fct+0x28:           ld.so.1`elf_get_so
ld.so.1`elf_fct+0x2c:           ld.so.1`elf_dladdr
ld.so.1`elf_fct+0x30:           ld.so.1`dlsym_handle
ld.so.1`elf_fct+0x34:           ld.so.1`elf_verify_vers
ld.so.1`elf_fct+0x38:           ld.so.1`elf_set_prot
ld.so.1`elf_secure_dirs:        ld.so.1`__rtld_msg+0x133e

与rt_fct类似的是Rt_map的另一个成员，rt_symintp，它实际上指向了真正的符号解析函数elf_find_sym:

....................................
0xd17fd964:     ld.so.1`elf_find_sym
....................................

正是elf_find_sym，完成了真正的符号表查找工作。

用mdb来遍历从0xd17fd900起始的Rt_map的双向链表：

> 0xd17fd900,6/nap
0xd17fd900:
0xd17fd900:     0x8050000    --->test加载地址
0xd17fd904:     0x8047ff5    --->Rt_map对应的二进制对象名,此处是test
0xd17fd908:     0x806071c
0xd17fd90c:     0xd17fdd40   --->后向指针,指向libc.so的link map
0xd17fd910:     0            --->前向指针，此处为NULL，表明是linkmap list的头
0xd17fd914:     0
> 0x8047ff5/s
0x8047ff5:      test         --->名字验证
> 0xd17fdd40,6/nap
0xd17fdd40:
0xd17fdd40:     0xd16e0000   --->libc.so加载地址
0xd17fdd44:     0xd17fdcd0   --->Rt_map对应的二进制对象名,此处是/lib/libc.so.1
0xd17fdd48:     0xd17afa3c
0xd17fdd4c:     0            ---->后向指针，是NULL，表明是linkmap list的尾
0xd17fdd50:     0xd17fd900   ---->前向指针，指向test的link map
0xd17fdd54:     0
> 0xd17fdcd0/s
0xd17fdcd0:     /lib/libc.so.1

与可执行文件不同，共享库中并没有在ELF文件的.text section头中规定共享库的加载地址，而只是给出了相对地址，待被装载后才重新确定：

# /usr/ccs/bin/elfdump -c -N .text /usr/lib/libc.so

Section Header[11]:  sh_name: .text
   sh_addr:      0x1f370         sh_flags:   [ SHF_ALLOC  SHF_EXECINSTR ]
   sh_size:      0x89895         sh_type:    [ SHT_PROGBITS ]
   sh_offset:    0x1f370         sh_entsize: 0
   sh_link:      0               sh_info:    0
   sh_addralign: 0x10

而实际上，通过遍历linkmap list，ld.so可以确定所有linkmap list中的二进制对象的实际装载地址。

这里libc.so的实际地址是0xd16e0000，可以通过pmap(1)验证得到的地址是否正确：

# pmap -x 1597
1597:   test
Address  Kbytes     RSS    Anon  Locked Mode   Mapped File
08046000       8       8       8       - rwx--    [ stack ]
08050000       4       4       -       - r-x--  test
08060000       4       4       4       - rwx--  test
D16C0000      24      12      12       - rwx--    [ anon ]
D16D0000       4       4       4       - rwx--    [ anon ]
D16E0000     764     764       -       - r-x--  libc.so.1
D17AF000      24      24      24       - rw---  libc.so.1
D17B5000       8       8       8       - rw---  libc.so.1
D17C8000     140     140       -       - r-x--  ld.so.1
D17FB000       4       4       4       - rwx--  ld.so.1
D17FC000       8       8       8       - rwx--  ld.so.1
-------- ------- ------- ------- -------
total Kb     992     980      72       -

同样的，共享库中符号表的st_value也不是该符号的绝对地址，而是偏移量，例如，libc.so中符号表中printf的取值是：

# /usr/ccs/bin/elfdump -s -N .dynsym /usr/lib/libc.so | grep " printf___FCKpd___70quot;
   [2416]  0x00061f39 0x00000105  FUNC GLOB  D   34 .text       printf

那么，如果lookup_sym函数得到printf在libc.so中的符号表记录的指针，那么很容易计算得出printf的绝对地址。

本例中，共享库中printf在符号表中st_value的取值和libc.so的装载地址都已经确定了，因此printf的绝对地址是：

> 0xd16e0000+0x00061f39=X
               d1741f39

如果用mdb反汇编这个地址，d1741f39就是printf在libc.so的真正入口：

> d1741f39::dis -w
libc.so.1`printf:               pushl  %ebp
libc.so.1`printf+1:             movl   %esp,%ebp
libc.so.1`printf+3:             subl   $0x10,%esp
libc.so.1`printf+6:             andl   $0xfffffff0,%esp
libc.so.1`printf+9:             pushl  %ebx
libc.so.1`printf+0xa:           pushl  %esi
libc.so.1`printf+0xb:           pushl  %edi
libc.so.1`printf+0xc:           call   +0x5     <libc.so.1`printf+0x11>
libc.so.1`printf+0x11:          popl   %ebx
libc.so.1`printf+0x12:          addl   $0x6d0b6,%ebx
libc.so.1`printf+0x18:          movl   0x244(%ebx),%esi

前面我们遍历link map是从0xd17fd900开始的，这个地址指向的Rt_map节点碰巧是整个linkmap list的头节点。实际上，0xd17fd900指向的Rt_map的准确含义是调用者的link map，假设符号解析的调用是从共享库发出的，那么这个地址指向的Rt_map就未必是头节点了。

实际上，每个进程的Rt_map都指向一个全局变量lml_main，通过该变量即可找到这个进程完整的linkmap list.

Rt_map结构成员rt_list指针就指向lml_main全局变量，它实际上是Lm_list结构，定义如下：

   799 extern Lm_list        lml_main;    /* main's link map list */

Lm_list定义如下：

   239 typedef    struct {
   240     /*
   241      * BEGIN: Exposed to rtld_db - don't move, don't delete
   242      */
   243     Rt_map        *lm_head;    /* linked list pointers to active */
   244     Rt_map        *lm_tail;    /*    link-map list */
   .....................................................................
   263 } Lm_list;

这样，实际上通过rt_list->lm_head即可定位到进程的linkmap list的头节点了，elf_bndr函数就是这样做的：

   250     sl.sl_cmap = lmp;                 --->指向调用者的Rt_map
   251     sl.sl_imap = LIST(lmp)->lm_head;  --->取得进程的link map list的头节点

因此，要确定给定符号存在于哪一个依赖的共享库时，需要遍历所有linkmap list中的节点时，就需要使用sl.sl_imap。

实际上，ld.so为mdb提供了专门的命令，以方便与ld.so相关的数据结构的查看：

让test进程运行：

# mdb test
> main+0x14:b
> :c
mdb: stop at main+0x14
mdb: target stopped at:
main+0x14:      call   -0x148   <PLT:printf>

装载ld.so模块：

> ::load ld.so

查看目前ld.so管理的所有Rt_map:

> ::Rt_maps
Link-map lists (dynlm_list): 0x8046368
----------------------------------------------
 Lm_list: 0xd17fb220  (LM_ID_BASE)
 ----------------------------------------------
   lmco        rtmap       ADDR()     NAME()
   ----------------------------------------------
   [0xc]       0xd17fd900 0x08050000 test
   [0xc]       0xd17fdd40 0xd16e0000 /lib/libc.so.1
 ----------------------------------------------
 Lm_list: 0xd17fb1e0  (LM_ID_LDSO)
 ----------------------------------------------
   [0xc]       0xd17fd590 0xd17c8000 /lib/ld.so.1

只查看test进程的Rt_maps列表：

> 0xd17fd900::Rt_maps -v
----------------------------------------------
Rt_map located at: 0xd17fd900
----------------------------------------------
    NAME: test
PATHNAME: /export/home/personal/blog/test
    ADDR: 0x08050000         DYN: 0x0806071c
    NEXT: 0xd17fdd40        PREV: 0x00000000
     FCT: 0xd17fb054    TLSMODID:          0
    INIT: 0x00000000        FINI: 0x00000000
  GROUPS: 0x00000000     HANDLES: 0x00000000
 DEPENDS: 0xd16d00d8     CALLERS: 0x00000000
 DYNINFO: 0xd17fda80     REFNAME:
   RLIST: 0x00000000       RPATH:
    LIST: 0xd17fb220 [ld.so.1`lml_main]
   FLAGS: 0x20421605
          [ ISMAIN,RELOCED,ANALYZED,INITDONE,FIXED,MODESET,INITCALL,INITCLCT ]
  FLAGS1: 0x00000602
          [ RELATIVE,NOINITFINI,USED ]
    MODE: 0x00001901
          [ LAZY,GLOBAL,WORLD,NODELETE ]
----------------------------------------------
Rt_map located at: 0xd17fdd40
----------------------------------------------
    NAME: /lib/libc.so.1
    ADDR: 0xd16e0000         DYN: 0xd17afa3c
    NEXT: 0x00000000        PREV: 0xd17fd900
     FCT: 0xd17fb054    TLSMODID:          0
    INIT: 0xd1788c10        FINI: 0xd1788c30
  GROUPS: 0x00000000     HANDLES: 0x00000000
 DEPENDS: 0xd16d02e0     CALLERS: 0xd16d0120
 DYNINFO: 0xd17fdee0     REFNAME:
   RLIST: 0x00000000       RPATH:
    LIST: 0xd17fb220 [ld.so.1`lml_main]
   FLAGS: 0x20420604
          [ RELOCED,ANALYZED,INITDONE,MODESET,INITCALL,INITCLCT ]
  FLAGS1: 0x00004402
          [ RELATIVE,USED,SYMSFLTR ]
    MODE: 0x00001901
          [ LAZY,GLOBAL,WORLD,NODELETE ]

查看test的Rt_map对用的Lm_list结构：

> 0xd17fb220::Lm_list
Lm_list: 0xd17fb220  (LM_ID_BASE)
----------------------------------------------
  lists: 0xd17fd3f0 Alist[used 1: total 8]
 ----------------------------------------------
   head: 0xd17fd900         tail: 0xd17fdd40      ---->可以看到，这里有link map list的头尾节点指针
  audit: 0x00000000      preexec: 0xd17fdd40
 handle: 0x00000000          obj:    2  init:    0  lazy:    0
  flags: 0x00000821
         [ BASELM,ENVIRON,STARTREL ]
 tflags: 0x00000000
>

不难想象，顺序遍历linkmap list，查找当前库是否包含printf符号，如果包含就返回指向符号表记录的指针，这就是lookup_sym接下来要做的工作。

3.3 算出符号绝对地址，并存储到GOT中该符号的对应项中

下面的代码相当容易理解：

   262     symval = nsym->st_value;
   263     if (!(FLAGS(nlmp) & FLG_RT_FIXED) &&
   264         (nsym->st_shndx != SHN_ABS))
   265         symval += ADDR(nlmp);

symval即printf在libc.so的符号表的st_value。nlmp则返回包含printf的libc的指向Rt_map指针的指针。

263行是保证包含给定符号库是不是固定地址映像的二进制文件，FLAGS(nlmp)可以从返回的Rt_map中得到二进制对象的类型。 264行则是判断取得的符号的类型是不是绝对地址。

libc.so是共享库，因此，最终运行到265行，将st_value与ADDR(nlmp)，即libc的基地址相加，得出绝对地址。

下面的代码会把printf的绝对地址存储到GOT[7]中,因此首先要得到GOT[7]的地址：

   281     if (!(rtld_flags & RT_FL_NOBIND)) {
   282         addr = rptr->r_offset;

在3.1小节，我们已经知道rptr->r_offset就对应着printf在GOT中的的地址，即GOT[7]地址。

下面对addr的改变只发生在当前调用者的Rt_map,即0xd17fd900指向的Rt_map,不是固定影射的二进制对象，我们知道test文件是固定影射的，因此下面2条语句在printf解析时，根本不会执行:

   283         if (!(FLAGS(lmp) & FLG_RT_FIXED))
   284             addr += ADDR(lmp);

最终，304行的语句会将printf的绝对地址存入GOT[7]中：

   285         if (((LIST(lmp)->lm_tflags | FLAGS1(lmp)) &
   286             (LML_TFLG_AUD_PLTENTER | LML_TFLG_AUD_PLTEXIT)) &&
   287             AUDINFO(lmp)->ai_dynplts) {
   ..............................................................................
   ..............................................................................
   ..............................................................................  
   299         } else {
   300             /*
   301              * Write standard PLT entry to jump directly
   302              * to newly bound function.
   303              */
   304             *(ulong_t *)addr = symval;
   305         }
   306     }

4. lookup_sym -> _lookup_sym -> elf_find_sym

实际上，为了提高在符号表中查找符号的效率，ELF文件中包含了一个.hash section，可以利用其中的hash表来进行符号查找：

# /usr/ccs/bin/elfdump -h test

Hash Section:  .hash
   bucket    symndx    name
        0  [1]         printf
        1  [2]         environ
           [3]         _PROCEDURE_LINKAGE_TABLE_
        3  [4]         _DYNAMIC
        5  [5]         _edata
           [6]         ___Argv
        6  [7]         _etext
           [8]         _init
        7  [9]         __fsr_init_value
        9  [10]        main
           [11]        _mcount
       10  [12]        _environ
       11  [13]        _GLOBAL_OFFSET_TABLE_
       15  [14]        _lib_version
       16  [15]        atexit
           [16]        __fpstart
       18  [17]        __fsr
           [18]        exit
           [19]        _get_exit_frame_monitor
       19  [20]        _end
           [21]        _start
       21  [22]        _fini
       24  [23]        __environ_lock
       27  [24]        __longdouble_used
       28  [25]        __1cG__CrunMdo_exit_code6F_v_

       12  buckets contain        0 symbols
       10  buckets contain        1 symbols
        6  buckets contain        2 symbols
        1  buckets contain        3 symbols
       29  buckets               25 symbols (globals)

ELF文件的.hash section提供了hash表本身，以及hash表元素的数目即nbuckets，每个hash表的bucket可能对应一个chain，chain的每一个元素是下一个符号在字符串表中的索引，这样这个chain相当于一个字符串索引值组成的list。这样，给定一个符号名，通过ELF规范定义的 hash函数，可以求得一个bucket号，再根据bucket号，遍历其对应的chain，对比字符串，来查找符号：

1. hn = elf_hash(sym_name) % nbuckets; 
2. for (ndx = hash[ hn ]; ndx; ndx = chain[ ndx ]) { 
3. symbol = sym_tab + ndx; 
4. if (strcmp(sym_name, str_tab + symbol->st_name) == 0) 
5. return (load_addr + symbol->st_value); }

利用mdb，我们可以得到完整的解析printf时的代码路径：

bash-3.00# mdb test
> main+0x14:b
> :c
mdb: stop at main+0x14
mdb: target stopped at:
main+0x14:      call   -0x148   <PLT:printf>
> ld.so.1`elf_find_sym::dis !grep strcmp
ld.so.1`elf_find_sym+0xbf:      call   +0x14e14 <ld.so.1`strcmp>
> ld.so.1`elf_find_sym+0xbf:b
> :c
mdb: stop at ld.so.1`elf_find_sym+0xbf
mdb: target stopped at:
ld.so.1`elf_find_sym+0xbf:      call   +0x14e14 <ld.so.1`strcmp>
> $c
ld.so.1`elf_find_sym+0xbf(80472e8, 80473ac, 80473b0)
ld.so.1`_lookup_sym+0x6e(d17fd900, 80472e8, 80473ac, 80473b0, c)
ld.so.1`lookup_sym+0x1d7(8047358, 80473ac, 80473b0)
ld.so.1`elf_bndr+0xf8(d17fd900, 18, 8050691)
ld.so.1`elf_rtbndr+0x14(18, 8050691, 80506ec, 80474f4, 80473e8, d17fb840)
0xd17fd900(1, 804742c, 8047434)
_start+0x7a(1, 804755c, 0, 8047561, 8047583, 8047597)
>

lookup_sym函数根据给定的符号名，通过hash函数算出其在hash表中的bucket号：


  2492     if (slp->sl_hash == 0)
  2493         slp->sl_hash = elf_hash(name);

_lookup_sym中循环遍历了linkmap list，对每个依赖库调用了SYMINTP来解析符号：

  2438     for (; lmp; lmp = (Rt_map *)NEXT(lmp)) {
  2439         if (callable(slp->sl_cmap, lmp, 0)) {
  2440             Sym    *sym;
  2441
  2442             slp->sl_imap = lmp;
  2443             if ((sym = SYMINTP(lmp)(slp, dlmp, binfo)) != 0)
  2444                 return (sym);
  2445         }
  2446     }

如果是ELF文件，SYMINTP对应的则是elf_find_sym函数，它在给定ELF对象的指定bucket中的chain list来查找符号。

查找对比符号必然要调用strcmp函数，因此我们可以利用dtrace脚本来观察这种比较是如何进行的：

#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN
{
      printf("Target pid: %d/n", $target);
}
pid$target::main:entry
{
      self->main=1;
}
pid$target::main:return
{
      self->main=0;
}
pid$target::elf_find_sym:entry
/self->main==1/
{
      self->trace=1;
}
pid$target::elf_find_sym:return
/self->main==1 && self->trace==1 /
{
      self->trace=0;
}
pid$target::strcmp:entry
/self->main==1 && self->trace==1 /
{
      printf("/n%s`%s(%s,%s)/n", probemod, probefunc,copyinstr(arg0),copyinstr(arg1));
}

运行dtrace脚本来观察每次elf_find_sym调用strcmp时的入口参数：

# ./test.d -c ./test
hello world
Target pid: 3934
LM1`ld.so.1`strcmp(rintf,rintf)
LM1`ld.so.1`strcmp(rintf,rintf)
LM1`ld.so.1`strcmp(edata,findbuf)
LM1`ld.so.1`strcmp(__Argv,findbuf)
..............................................

可以看到，strcmp在查找printf时只对比了rintf而不是printf，这是为什么呢？查看代码可以找到答案：

  1869         if ((*strtabname++ != *name) || strcmp(strtabname, &name[1])) {
  1870             if ((ndx = chainptr[ndx]) != 0)
  1871                 continue;
  1872             return ((Sym *)0);
  1873         }
  1874

1869行代码是一个语言或表达式，首先比较两个字符串的首字符，如果不相等，则或表达式已经为真，接下来的strcmp就不会被执行。这样做，可以减低符号查找时带来的调用strcmp的开销。