含大量图文解析及例程 | Linux下的ELF文件、链接、加载与库（下）

刘盼

发布于 2022-08-26 15:53:58

1.4K0

发布于 2022-08-26 15:53:58

文章被收录于专栏：人人都是极客

入口函数和运行库

入口函数

初学者可能一直以来都认为C程序的第一条指令就是从我们的main函数开始的，实际上并不是这样，在main开始前和结束后，系统其实帮我们做了很多准备工作和扫尾工作，下面这个例子可以证明：

我们有两个C代码：

// entry.c
#include <stdio.h>

__attribute((constructor)) void before_main()
{ printf("%s\n",__FUNCTION__); }

int main() {
    printf("%s\n",__FUNCTION__);
}


// atexit.c
#include <stdio.h>

void post(void)
{
    printf("goodbye!\n");
}

int main()
{
    atexit(&post);
    printf("exiting from main\n");
}

分别编译运行这两个程序，输出结果分别为：

# entry.c
before_main
main
# atexit.c
exiting from main
goodbye!

可见，在main开始前和结束后，其实还有一部分程序在运行。

事实上操作系统装载程序之后首先运行的代码并不是我们编写的main函数的第一行，而是某些运行库的代码，它们负责初始化main函数正常执行所需要的环境，并负责调用main函数，并且在main返回之后，记录main函数的返回值，调用atexit注册的函数，最后结束进程。以Linux的运行库glibc为例，所谓的入口函数，其实就是指ld 默认的链接脚本所指定的程序入口_start (默认情况下)。

运行库

glibc = GNU C library

Linux环境下的C语言运行库glibc包括：

启动和退出相关的函数
C标准库函数的实现 (标准输入输出，字符处理，数学函数等等)
…

事实上运行库是和平台相关的，和操作系统联系的非常紧密，我们可以把运行库理解成我们的C语言(包括c++)程序和操作系统之间的抽象层，使得大部分时候我们写的程序不用直接和操作系统的API和系统调用直接打交道，运行库把不同的操作系统API抽象成相同的库函数，方便应用程序的使用和移植。

Glibc有几个重要的辅助程序运行的库 /usr/lib64/crt1.o, /usr/lib64/crti.o, /usr/lib64/crtn.o。

其中crt1包含了基本的启动退出代码， ctri和crtn包含了关于.init段及.finit段相关处理的代码(实际上是_init()和_finit()的开始和结尾部分)

Glibc是运行库，它对语言的实现并不太了解，真正实现C++语言特性的是gcc编译器，所以gcc提供了两个目标文件crtbeginT.o和crtend.o来实现C++的全局构造和析构 – 实际上以上两个高亮出来的函数就是gcc提供的，有兴趣的读者可以自己翻阅gcc源代码进一步深入学习。

几组概念的辨析

动态链接的可执行文件和共享库文件的区别

问题: 可执行文件和动态库之间的区别？我们在第一节中提到过动态链接的可执行文件和动态库文件file命令的查看结果是类似的，都是shared object，一个不同之处在于可执行文件指明了解释器intepreter：

可执行文件和动态库之间的区别，简单来说：可执行文件中有main函数，动态库中没有main函数，可执行文件可以被程序执行，动态库需要依赖程序调用者。

在可执行文件的所有符号中，main函数是一个很特别的函数，对C/C++程序开发人员来说，main函数是整个程序的起点；但是，main函数却不是程序启动后真正首先执行的代码。

除了由程序员编写的源代码编译成目标文件进而链接到程序内存映射，还有一部分机器指令代码是在链接过程中添加到程序内存映射中。比如，程序的启动代码，放在内存映射的起始处，在执行main函数之前执行以及在程序终止后完成一些任务编译动态库时，链接器没有添加这部分代码。这是可执行文件和动态库之间的区别。

静态链接 / 动态链接的可执行文件的第一条指令地址

静态链接可执行文件的第一条指令地址

我们之前提到过，静态链接的可执行文件的其实地址就是本文件的_strat，即readelf -h所得到的的起始地址。对于一个hello程序：

// hello.c
#include <stdio.h>

int main(){
    printf("Hellow World.\n");
    return 0;
}

我们先用选项-static来静态链接它，得到hello-st：

gcc -static hello.c -o hello-st

我们先用file命令看一下：

它是静态链接的可执行文件。

我们用readelf -h查看其入口地址，并在gdb中starti查看它实际的第一条指令的地址：

可以看到，与我们的预期是一致的，确是是从文件本身真正的入口地址entry point0x400a50开始执行第一条指令。而在动态链接的可执行文件中，我们将看到不同。

动态链接的可执行文件的第一条指令地址

我们现在动态链接（默认）编译hello程序得到hello-dy：

gcc hello.c -o hello-dy

还是先来file一下：

我们看到hello-dy是一个动态链接的共享目标文件，当然它也是可执行的，共享库文件和可执行的共享目标文件的区别我们上面已经介绍过了。大家注意，这里还多了一个奇怪的家伙：解释器，interpreter /lib64/ld-linux-x86-64.so.2。

实际上，它就是动态链接文件的链接加载器。我们之前已经介绍过，在动态链接的可执行文件中，外部符号的地址在程序加载、运行的过程中才被确定下来。这个链接加载器 ld 就是负责完成这个工作的。当 ld 将外部符号的地址都确定好之后，才将指令指针执行程序本身的_start。也就是说，在动态链接的可执行文件中，第一条指令应该在链接加载器 ld 中。我们接下来还是通过readelf -h和gdb来验证一下。