精致全景图 | 程序是如何运行起来的

[导读]因为图片比较大，微信公众号上压缩的比较厉害，所以很多细节都看不清了，我单独传了一份到github上，想要原版图片的，可以点击下方的阅读原文，或者直接使用下面的链接，来访问github：https://github.com/wangyuntao/linux-kernel-illus...

因为图片比较大，微信公众号上压缩的比较厉害，所以很多细节都看不清了，我单独传了一份到github上，想要原版图片的，可以点击下方的阅读原文，或者直接使用下面的链接，来访问github：

另外，精致全景图系列文章，以及之后的linux内核分析文章，我都会整理到这个github仓库里，欢迎大家star收藏。

相信很多同学都会有疑问，一个程序是如何运行起来的，为什么我们在shell中执行了一个程序，它的main函数就会被调用呢？在main函数被调用之前及之后，又经历了什么呢？

今天我们就来详细的说下这个问题。

还是和之前一样，我画了一张程序运行的全景图，在上图中，一个程序运行所经历的代码段，我都标注了其所在的git仓库、源文件、及函数名，想要自己看源码的，可以参考下上图中的这些信息。

我们先从整体上讲一下这张图。

在linux下，我们一般都是通过shell来执行程序的。

shell其实也是一个普通的程序，它也有自己的main函数，它在正常运行后，会通过调用read_command函数，来等待用户输入命令。

在接收到用户输入的命令后，shell会先使用fork系统调用，创建一个子进程，然后再在这个子进程中，通过execve系统调用，执行最终的用户程序。

在子进程执行用户程序期间，shell主进程会调用waitpid函数，阻塞等待子进程的完成，子进程完成之后，waitpid从阻塞状态中返回，且status参数中会带着子进程的退出码，这个退出码会在后续的逻辑中被保存起来，供用户查询。

之后，shell主进程进入到下一次循环，继续等待用户输入命令并执行。

以上就是shell的主体逻辑，对应于上面全景图中的蓝色部分。

下面我们再来看下linux内核中有关execve系统调用的代码，也就是上面全景图中的绿色部分。

shell通过execve系统调用，告知linux内核，要在当前进程中执行目标程序，linux内核经过层层代码，最终到达load_elf_binary函数。

该函数是整个系统调用中最核心的一段逻辑，它主要用来为目标程序准备各种执行环境。

比如，映射代码区、数据区等到当前进程的虚拟地址空间，将程序名、环境变量、程序参数、及各种其他数据，有规律的压入到新分配的栈中，等等。

之后，load_elf_binary函数会调用start_thread，进而会调用start_thread_common函数。

在该函数里，会将返回到用户区之后，要执行的，用户区程序的起始地址，设置到regs->ip里，同时也会将上面新初始化好的，用户堆栈的栈顶地址，设置到regs->sp里。

当execve系统调用返回到用户区之后，regs->ip和regs->sp里的值，会分别赋值到rip和rsp寄存器里，这样指定的用户程序就可以继续执行了。

这一流程我们在之前的文章精致全景图 | 系统调用是如何实现的中讲过，这里就不再赘述。

不过这里还是有一点需要注意，就是设置到regs->ip中的地址，并不是我们自己程序的起始地址，而是动态链接器 /lib64/ld-linux-x86-64.so.2 的起始地址。

之所以要设置动态链接器的起始地址，是因为我们需要在返回到用户区之后，让其可以继续为我们的程序准备执行环境，比如，帮忙加载程序依赖的各种动态链接库等。

在动态链接器为我们的程序准备好执行环境之后，它会从进程堆栈的auxiliary vector区，取出最终用户程序的真正起始地址，并跳转到该位置开始执行。

auxiliary vector区存放的用户程序的起始地址，是上面linux内核初始化堆栈时设置的。

动态链接器相关的代码就是这些，它对应于上面全景图中紫色的部分。

在跳转到我们自己程序的起始地址后，首先执行的并不是我们写的main函数，而是glibc里名为_start的一段汇编代码。

这段汇编代码也比较简单，主要是从堆栈中获取main函数所需的argc，argv等参数，然后最终调用我们写的main函数。

当main函数返回之后，glibc里的后续代码，会将main函数的返回值，当作该进程的退出码，然后调用exit结束该进程。

这些代码对应于上面全景图中的粉色部分。

进程调用exit退出之后，shell主进程也会从waitpid的阻塞状态中返回，然后继续进行下一次循环。

以上就是程序完整的启动和结束流程。

下面我们来看下具体的源码实现。

注意，为了方便理解，很多代码我们都做了删减。

首先是shell部分，shell是一个普通的程序，它也有自己的main函数：

该函数里调用了reader_loop：

reader_loop的主体逻辑是，在while循环里不断的使用read_command函数读取用户输入的命令，然后使用execute_command执行该命令。

execute_command函数经过层层代码后，会使用下图中的fork，创建一个子进程：

然后在该子进程中，使用execve系统调用，告知linux内核，用当前子进程执行新的用户程序：

在shell主进程中，会调用waitpid函数，阻塞等待子进程的完成：

当子进程退出后，waitpid会从阻塞状态中返回，并在status里携带子进程的退出码，之后shell主进程又返回上面的read_command函数，继续等待用户下一条命令的输入。

以上就是bash的主体逻辑，对应于上面全景图中的蓝色部分。

下面我们继续看全景图中的绿色部分，也就是linux内核中有关execve的代码。

当shell的子进程执行execve函数时，linux内核中对应的系统调用被触发：

沿着函数的调用链，我们会找到一个名为do_execveat_common的函数，在该函数中，会将目标程序的文件名、环境变量、及各种程序参数等字符串，拷贝到新创建的用户堆栈区：

此时，新创建的堆栈区里内容，就如上面全景图中右下角的a1-a9, b1-b8部分构成的二维网格区域里所示的内容。

其中，黄色区域里存放的是程序参数 ./a.out hello world，蓝色区域里存放的是环境变量 SHLVL=2, HOME=/, TERM=linux, PWD=/，橘黄色区域里存放的是要执行的程序文件名 ./a.out。

这些内容和我们执行的测试程序，及其所处的环境也正好一样：

继续沿着内核函数调用链，我们最终会来到load_elf_binary函数，该函数是整个系统调用的核心。

由于linux上执行的程序基本上都是elf格式，所以内核选择的加载函数是load_elf_binary，看这个函数时，可以参考elf格式的man文档：

https://man.archlinux.org/man/elf.5

该函数比较复杂，我对其做了大量删减，并添加了很多注释：

该函数最后会调用start_thread函数，进而会调用start_thread_common函数：

这个函数重点需要注意的是对regs->ip和regs->sp的赋值，其作用在load_elf_binary函数的截图中已经注释过了，就是在返回到用户区之后，这两个字段的值会被分别拷贝到rip和rsp寄存器里，所以这里的赋值，就相当于在返回用户区之后，对rip和rsp寄存器的赋值，这个在精致全景图 | 系统调用是如何实现的有讲。

到这里内核部分的代码就都已经结束了。

由load_elf_binary函数截图中可见，regs->ip中设置的地址是elf_entry，即动态链接器的起始地址，而不是我们自己程序的起始地址。

原因是，我们还需要动态链接器继续帮我们准备执行环境，比如帮我们加载程序依赖的动态链接库等。

所以在execve系统调用返回到用户区之后，代码流程就进入到了动态链接器里的逻辑，即上面全景图中的紫色区域：

上图中的_start是动态链接器的起始执行地址，这个可以通过下面的方式来确认：

在_start函数中，先将rsp寄存器的值，即上面内核新初始化的堆栈的栈顶地址，赋值到rdi中，然后再使用call指令，调用_dl_start函数。

之所以要赋值到rdi寄存器中，是因为c语言的calling convention约定好的，用此方式来传递参数。

再看_dl_start函数：

该函数调用了_dl_start_final，返回一个地址，这个地址就是我们自己程序的起始地址。

再看_dl_start_final：

该函数又调用了_dl_sysdep_start：

在这里，动态链接器通过内核初始化的堆栈区中的auxiliary vector，找到最终用户程序的起始执行地址。