9.漫谈兼容内核之九：ELF映像的装入_二_.pdf

漫谈兼容内核之九: ELF 映像的装入(二) 毛德操 上一篇漫谈介绍了在通过 execve()系统调用启动一个 ELF 格式的目标映像时发生于 Linux 内核中的活动。简而言之，内核根据映像头部所提供的信息把目标映像映射到(装入) 当前进程用户空间的某个位置上；并且，如果目标映像需要使用共享库的话，还要(根据映 像头部所提供的信息)将所需的“解释器”的映像也映射到用户空间的某个位置上，然后在 从系统调用返回用户空间的时候就“返回”到解释器的入口，下面就是解释器的事了。如果 目标映像不使用共享库，那么问题就比较简单，返回用户空间的时候就直接“返回”到目标 映像的入口。现代的应用软件一般都要使用共享库，所以我们把这当作常态，而把不使用共 享库的应用软件作为一种简化了的特例。 映像装入用户空间的位置有些是固定的、在编译连接时就确定好了的；有些则是“浮动” 的、可以在装入时动态决定；具体要看编译时是否使用了-fPIC 选项。一般应用软件主体的 映像都是固定地址的，而共享库映像的装入地址都是浮动的。特别地，解释器映像的装入地 址也是浮动的。 2 ．ELF 映像的结构 每个操作系统对于在其内核上运行的可执行程序二进制映像都有特定的要求和规定，包 括例如映像的格式，映像在用户空间的布局(程序段、数据段、堆栈段的划分等等) ，映像装 入用户空间的地址是否可以浮动、以及如何浮动，是否支持动态连接、以及如何连接，如何 进行系统调用，等等。这些要求和规定合在一起就构成了具体操作系统的“应用(软件)二进 制界面(Application Binary Interface) ”，缩写成ABI 。显然，ABI 是二进制映像的“生产者” 即编译/连接工具和使用者即映像装入/启动手段之间的一组约定。而我们一般所说的二进制 映像格式，实际上并不仅仅是指字面意义上的、类似于数据结构定义那样的“格式”，还包 括了跟映像装入过程有关的其它约定。所以，二进制映像格式是 ABI 的主体。 目前的Linux ABI 是在 Unix 系统 5 的时期(大约在 1980 年代)发展起来的，其主体就是 ELF ，这是“可执行映像和连接格式(Executable and Lnking Format) ”的缩写。 读者已经看到，ELF 映像文件的开始是个 ELF 头，这是一个数据结构，结构中有个指 针(位移量) ，指向文件中的一个“程序头”数组(表) 。各个程序头表项当然也是数据结构， 这是对映像文件中各个“节(Segment) ”的(结构性)描述。 从映像装入的角度看，一个映像是由若干个 Segment 构成的。有些 Segment 需要被装入、 即被映射到用户空间，有些则不需要被装入。在前一篇漫谈中读者已经看到，只有类型为 PT_LOAD 的 Segment 才需要被装入。所以，映像装入的过程只“管”到 Segment 为止。而 从映像的动态连接、重定位(即浮动) 、和启动运行的角度看，则映像是由若干个“段(Section)” 构成的。我们通常所说映像中的“代码段”、“数据段”等等都是Section。所以，动态连接 和启动运行的过程所涉及的则是 Section。一般而言，一个 Segment 可以包含多个 Section。 其实，Segment 和 Section 都是从操作/处理的角度对映像的划分；对于不同的操作/处理，划 分的方式也就可以不同。所以，读者在后面将会看到，一个 Segment 里面也可以包含几个别 的 Segment，这就是因为它们是按不同的操作/处理划分的、不同意义上的 Segment。Section 也是一样。 在 Linux 系统中，(应用软件主体) 目标映像本身的装入是由内核负责的，这个过程读者 已经看到；而动态连接的过程则由运行于用户空间的“解释器”负责。这里要注意：第一， “解释器”是与具体的映像相连系的，其本身也有个映像，也需要被装入。与目标映像相连 系的“解释器”也是由内核装入的，这一点读者也已看到。第二，动态连接的过程包括了共 享库映像的装入，那却是由“解释器”在用户空间实现的。 本来，看了内核中与装入目标映像有关的代码以后，应该接着看“解释器”的代码了。 但是后者比前者复杂得多，也繁琐得多，原因是牵涉到许多 ELF 和 ABI 的原理和细节，所 以有必要先对 ELF 动态连接的原理作一介绍。