《漫谈兼容内核之八elf映像的装入一paper》由会员分享，可在线阅读，更多相关《漫谈兼容内核之八elf映像的装入一paper（44页珍藏版）》请在金锄头文库上搜索。
1、漫谈兼容内核之八 : Talk compatible with the kernel of the eight:ELF 映像的装入 ( 一 )ELF image into (a)毛德操 Maud operation 上一篇漫谈中介绍了 Wine 的二进制映像装入和启动，现在我们来看看 ELF 映像的装入和启动。 Talk on the one described in the Wine and start loading the binary image, and now we look into the ELF image and start. 一般而言，应用软件的编程不可能是“一竿子到底”
2、、所有的代码都自己写的，程序员不可避免地、也许是不自觉地、都会使用一些现成的程序库。 Generally speaking, application software programming can not be a pole in the end, all write their own code, programmers inevitably, perhaps unconsciously, will use some ready-made library. 对于 C 语言的编程，至少 C 程序库是一定会用到的。 For the C programming language, at leas
3、t C library would definitely be used. 从编译 / 连接和运行的角度看，应用程序和库程序的连接有两种方法。 From the compile / link and run the point of view, applications, and database connectivity programs in two ways. 一种是固定的、静态的连接，就是把需要用到的库函数的目标 ( 二进制 ) 代码从程序库中抽取出来，连接进应用软件的目标映像中，或者甚至干脆把整个程序库都连接进应用软件的映像中。 One is fixed, static connec
4、tions, is the need to use the library function of the target (binary) code extracted from the program library, connect the target image into the application software, or even simply to enter the library are connected application image. 这里所谓的连接包括两方面的操作，一是把库函数的目标代码“定位”在应用软件目标映像中的某个位置上。 Here the so-cal
5、led connection consists of two aspects of the operation, one goal of the library function code positioning in the application software to a target location in the image. 由于不同应用软件本身的大小和结构都可能不同，库函数在目标映像中的位置是无法预先确定的。 Because different applications have their own size and structure may be different, the
6、 librarys position in the target image can not be predetermined. 为此，程序库中的代码必须是可以浮动的，即“与位置无关”的，在编译时必须加上 -fPIC 选项，这里 PIC 是“ Position-Independent Code ”的缩写。 To this end, the library code must be floating, that is position independent, and must be compiled with-fPIC option, where the PIC is the Position
7、-Independent Code acronym. 一旦一个库函数在映像中的位置确定以后，就要使应用软件中所有对此函数的调用都指向这个函数。 Once a library function to determine the location in the image after the application software will make all the calls to this function to point to this function. 早期的软件都采用这种静态的连接方法，好处是连接的过程只发生在编译 / 连接阶段，而且用到的技术也比较简单。 Early softwa
8、re connection with this static method, the benefits of the process is connected only in the compile / link phase, and the use of technology is relatively simple. 但是也有缺点，那就是具体库函数的代码往往重复出现在许多应用软件的目标映像中，从而造成运行时的资源浪费。 But there are drawbacks, it is often the specific library function code is repeated in
9、 many applications the target image, resulting in waste of resources when running. 另一方面，这也不利于软件的发展，因为即使某个程序库有了更新更好的版本，已经与老版本静态连接的应用软件也享受不到好处，而重新连接往往又不现实。 On the other hand, this is not conducive to the development of software, because even if a library with newer and better version of the old versio
10、n has been statically linked with the application software can not enjoy the benefits of re-connection is often not reality. 再说，这也不利于将程序库作为商品独立发展的前景。 Moreover, this library is not conducive to the prospect of independent development as a commodity. 于是就发展起了第二种连接方法，那就是动态连接。 So from the second connecti
11、on on the development of methods, that is the dynamic connection. 所谓动态连接，是指库函数的代码并不进入应用软件的目标映像，应用软件在编译 / 连接阶段并不完成跟库函数的连接；而是把函数库的映像也交给用户，到启动应用软件目标映像运行时才把程序库的映像也装入用户空间 ( 并加以定位 ) 、再完成应用软件与库函数的连接。 The so-called dynamic link library function of the code is not the target image into the application softwa
12、re, application software at compile / link phase does not complete the connection with the library function; but also to the image library to the user, to start the application software to run only when the target image image library into the user space is also (and to locate), and then complete the
13、 application connection with library functions. 说到程序库，最基本、最重要的当然是 C 语言库、即 libc 或 glibc 。 Speaking of libraries, the most basic and important of course is the C language library, that is, libc or glibc. 这样，就有了两种不同的 ELF 格式映像。 Thus, there are two different ELF format image. 一种是静态连接的，在装入 / 启动其运行时无需装入函数库
14、映像、也无需进行动态连接。 One is a static connection, in the load / start the runtime libraries do not need to load the image, no need for dynamic connectivity. 另一种是动态连接的，需要在装入 / 启动其运行时同时装入函数库映像并进行动态连接。 The other is the dynamic connection, you need to load / start the run into the library at the same time the d
15、ynamic image and connection. 显然， Linux 内核应该既支持静态连接的 ELF 映像、也支持动态连接的 ELF 映像。 Obviously, Linux kernel should support both statically linked ELF images, dynamically linked ELF also supports image. 进一步的分析表明：装入 / 启动 ELF 映像必需由内核完成，而动态连接的实现则既可以在内核中完成，也可在用户空间完成。 Further analysis shows that: load / start the
16、 ELF image must be completed by the kernel, and implementation of dynamic linking is done either in the kernel can also be done in user space. 因此， GNU 把对于动态连接 ELF 映像的支持作了分工：把 ELF 映像的装入 / 启动放在 Linux 内核中；而把动态连接的实现放在用户空间，并为此提供一个称为“解释器”的工具软件，而解释器的装入 / 启动也由内核负责。 Therefore, GNU ELF dynamically linked to the support of the image made division of labor: the ELF image into / boot on the Linux kernel; and the realization of the dynamic link on the user space, and provide a feature calle
