漫谈兼容内核之九：ELF映像的装入(二).docVIP

漫谈兼容内核之九：ELF映像的装入(二).txt我们用一只眼睛看见现实的灰墙，却用另一只眼睛勇敢飞翔，接近梦想。男人喜欢听话的女人，但男人若是喜欢一个女人，就会不知不觉听她的话。漫谈兼容内核之九:ELF映像的装入(二) [align=center][size=4][b]漫谈兼容内核之九:ELF映像的装入(二)[/b][/size][/align] [align=center]毛德操[/align] 上一篇漫谈介绍了在通过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动态连接的原理作一介绍。明白了有关的原理和大致的方法以后，具体的代码实现倒在其次了。 前面讲过，Linux提供了两个很有用的工具，即r