因为图片比较大，微信公众号上压缩的比较厉害，所以很多细节都看不清了，我单独传了一份到github上，想要原版图片的，可以点击下方的阅读原文，或者直接使用下面的链接，来访问github：
https://github.com/wangyuntao/linux-kernel-illustrated
另外，精致全景图系列文章，以及之后的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，找到最终用户程序的起始执行地址。
再之后，动态链接器的函数调用链依次退出，最终返回到上面的_start函数。
_start函数之后会顺序执行_dl_start_user，相关代码也在上面的_start函数的截图里。
其逻辑是，先将rax中的值，即_dl_start函数返回的最终用户程序的起始地址，赋值到r12寄存器中，然后再jmp到r12寄存器指向的地址，即开始执行最终的用户程序逻辑。
至于rax中的值，为什么是_dl_start函数返回的地址，这个其实也是 c calling convention 中的约定，感兴趣可以自己查下。
以上就是动态链接器的全部逻辑，其对应于全景图中的紫色部分。
最后，逻辑进入到了全景图中的粉色部分。
动态链接器从内核设置的auxiliary vector中，获取的用户程序的起始地址，还并不是我们的main函数，而是glibc中一段名为_start的代码，这个可以通过下面的方式确认：
该_start代码段内容如下：
它从堆栈中获取到argc和argv，然后调用__libc_start_main：
在__libc_start_main里，才真正的调用了我们写的main函数。
当main函数返回之后，__libc_start_main里用main函数返回的值，作为该进程的退出码，然后调用exit退出当前进程。
当该进程退出后，shell主进程也从waitpid的阻塞状态返回，并携带用户程序的退出码。
在上面全景图这个示例中，返回码为99：
之后，shell主进程又进入到下一次循环，继续等待用户命令并执行，也就是说，又进入到全景图中的蓝色部分。
至此，在linux上执行程序的流程，就形成了一个完整闭环。
你，学废了吗?
本文转载自微信公众号「卯时卯刻」，可以通过以下二维码关注。转载本文请联系卯时卯刻公众号。
