Linux 动态函式库解析(二)

　　很明显的，我们可以看到动态函式库在 Linux 环境中所发挥的妙用，它大幅的降低了整体环境的持有成本，提高了环境空间的利用率。

　　ld-linux.so.2 在 RedHat 6.1 中，我们可以在 /lib 或是 /usr/lib 目录底下找到许多系统上所安装的动态函式库，在文章的这个部分，笔者将把整个函式库大略的架构作一个说明。

　　其实 Linux 跟 Windows 一样，提供了一组很基本的动态函式库，在 Windows 上面我们知道 kernel32.dll 提供了其它动态函式库基本的函式呼叫，而在 Linux 上面则透过 ld-linux.so.2 提供了其它动态函式库基本的函式，在笔者电脑的 RedHat6.1 上，ld-linux.so.2 是透过 link 到 ld-2.1.2.so(这部分需视各人所使用的 glibc 版本不同而定)

-rwxr-xr-x 1 root root 368878 Jan 20 14:28 ld-2.1.2.so 
lrwxrwxrwx 1 root root 11 Jan 20 14:28 ld-linux.so.2 -> ld-2.1.2.so 

　　ld-linux.so 是属於 Glibc (GNU C Library) 套件的一部分，只要是使用 Glibc 动态函式库的环境，就可以见到 ld-linux.so 的踪影。

　　接下来，我们透过指令 ldd 来验证出各个函式库间的阶层关系，首先如下图我们执行了 ”ldd ls”、”ldd pwd” 与 “ldd vi”，可以看出各个执行档呼叫了哪些动态函式库，像执行档 ls 呼叫了 /lib/libc.so.6 (0x40016000)与 /lib/ld-linux.so.2 (0x40000000)，而括号内的数字为该函式库载入记忆体的位置，在本文的稍後，会介绍到函式库载入时的细节，到时读者会有更深入的了解。

　　其实我们不难发现，在 Linux 上使用动态函式库的执行档，几乎都会去呼叫 libc.so.6 与 ld-linux.so.2 这两个动态函式库，笔者过去修改 Glibc 的套件时，也了解到在 Linux 中函式库的关系，ld-linux.so.2 算是最底层的动态函式库，它本身为静态联结，主要的工作是提供基本的函式给其他的函式库，而我们最常会呼叫的 libc.so.6 则是以 ld-linux.so.2 为基础的一个架构完成的动态函式库，它几乎负责了所有我们常用的标准 C 函式库，像是我们在 Linux 下写的 Socket 程序，其中的connect()、bind()、send() .....之类的函式，都是由 libc.so.6 所提供的。

　　也因此，libc.so.6 的大小也是相当可观的，在 RedHat 6.1 中经过 strip 後，大小约为 1052428 bytes。

[root@hlchoua /root]# ldd /bin/ls 
libc.so.6 => /lib/libc.so.6 (0x40016000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
[root@hlchoua /root]# ldd /bin/pwd 
libc.so.6 => /lib/libc.so.6 (0x40016000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
[root@hlchoua /root]# ldd /bin/vi 
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40016000) 
libc.so.6 => /lib/libc.so.6 (0x4001b000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 

　　如下，我们透过 ldd 验证 vi 所用到的动态函式库 /lib/libtermcap.so.2，它本身是呼叫了 libc.so.6 的函式所组成的。

[root@hlchoua /root]# ldd /lib/libtermcap.so.2 
libc.so.6 => /lib/libc.so.6 (0x40007000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) 

　　接下来，我们依序测试了 /lib/libc.so.6 与 /lib/ld-linux.so.2

[root@hlchoua /root]# ldd /lib/libc.so.6 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
[root@hlchoua /root]# ldd /lib/ld-linux.so.2 
statically linked 

　　我们可以整理以上的结论，画成如下的一个架构图

　　<img src=http://linuxfab.cx/Columns/97/libc.gif <

　　在这个图中，我们可以清楚的明白 ld-linux.so.2 负责了最基础的函式，而 libc.so.6 再根据这些基本的函式架构了完整的 C 函式库，供其它的动态函式库或是应用程序来呼叫。

　　透过笔者所写的一个 ELF 工具程序(注二)，我们也可以清楚的看到 libc.so.6呼叫了 ld-linux.so.2 哪些函式

[root@hlchoua /root]# /I-elf /lib/libc.so.6|more 
======================================================== 
open_target_file:/lib/libc.so.6 
==>ld-linux.so.2 
__register_frame_table 
cfsetispeed 
xdr_int32_t 
utmpname 
_dl_global_scope_alloc 
__strcasestr 
hdestroy_r 
rename 
__iswctype_l 
__sigaddset 
xdr_callmsg 
pthread_setcancelstate 
xdr_union 
__wcstoul_internal 
setttyent 
strrchr 
__sysv_signal ...┅(more) 

　　其实，ldd 指令为一个 shell script 的档案，它主要是透过呼叫 ”run-time dynamic linker” 的命令，并以 LD_TRACE_LOADED_OBJECTS 为参数来秀出这些结果的。

　　如下，就是我们不透过 ldd 指令直接以 eval 搭配 LD_TRACE_LOADED_OBJECTS参数来检视 libcrypt.So.1 与 libm.so.6这两个动态函式库的结果。

[root@hlchoua /root]# eval LD_TRACE_LOADED_OBJECTS=1 /lib/libcrypt-
2.1.2.so 
libc.so.6 => /lib/libc.so.6 (0x40016000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
[root@hlchoua /root]# eval LD_TRACE_LOADED_OBJECTS=1 /lib/libm.so.6 
libc.so.6 => /lib/libc.so.6 (0x40016000) 
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)