可执行文件的装载和进程

进程的创建

创建独立的虚拟空间

所谓的创建空间实际上不是真的在内存中申请相应的空间，而是创建代码虚拟空间到内存的物理空间页映射结构，
实际上可能只是申请一个页目录，等到真正执行代码的时候，产生了缺页错误再去映射物理页，拷贝需要执行的代码。

读取可执行文件头，创建虚拟空间和可执行文件映射关系

 程序执行时，发生缺页错误，内核从物理页中分配一个页，在将该缺页从存储拷贝到物理内存中，再设置物理页和虚拟页的映射关系，
 但是有个问题是这个要读取的虚拟页怎么就是我们要执行的代码+数据段呢？
 因此就产生了虚拟空间和可执行文件之间的映射过程。
 只有创建了这个映射，可执行代码才真正能以页的组织形式加载到物理页中去执行。

如何理解可执行文件，虚拟空间，物理空间，VMA的关系

 可执行文件，虚拟空间，物理空间，这三个概念里，可执行文件是代码的组织视图，是编译链接后形成的，是静态的；
 虚拟空间和物理空间是代码执行期间的概念，是运行期间的组织方式，是动态的（系统管理内存的单元就是页），
 只不过可执行文件看到的是整个虚拟空间，但是受到物理限制，系统将其转换到了物理空间。
  VMA是visual Memory Address，上图中0x08048000-0x08049000就是一段VMA，
  **内核使用虚拟空间不是没有章法的， 他将代码段 ，数据段，堆，栈等一个进程要使用到的所有功能模块组织起来的概念，就是一段段的VMA**。

设置CPU指令寄存器的入口地址 开始运行

	执行完上面的操作，CPU PC指针指向可执行文件入口地址， 操作系统将系统的运行权限交给进程，开始执行进程代码

进程栈的初始化

	堆栈顶部往下，分别是环境变量，初始参数，环境变量指针，初始参数指针，初始参数个数，开始运行后，
	esp指针(指向初始参数个数和初始参数指针)地址会被传给入口函数main，也就是我们熟知的argc ,argv参数。

页错误

	CPU在执行进程在指令的时候，发现要执行的VMA（visual Memory Address）空间是空的，
	会产生缺页错误，于是将控制权交给系统，系统的缺页程序查询执行的VMA和可执行文件之间的映射结构体，
	知道了相应代码在可执行文件中的偏移地址，分配物理页，拷贝代码段，把执行权限返回给CPU继续执行，循环往复。
	当系统存在大量的执行进程，可能会导致物理内存不足，这需要系统特别关注分配的效率，就涉及到虚拟内存管理和回收功能了。

进程的虚拟空间分布

可执行文件的链接视图和执行视图

由于实际执行的时候不只有代码段，有相应的数据段和只读数据段需要加载，当我们加载段到VMA中的时候都是以整数倍的页来安排，
![请添加图片描述](https://img-blog.csdnimg.cn/868b268a123d442994e27a1c2f3d4d28.png)

如果一个物理页只加载一个对应的段，可能会产生大量的页空间浪费，因此他们的组织形式就成了系统需要考虑的问题。
实际上系统不关心代码 数据在可执行文件中是怎么安排的，他们关心的是段的属性：

由此形成了代码的执行视图,他的组织方式叫segment，segment包含多个属性相同的段，存放于确定稿属性的VMA中，便于系统处理访问：

堆和栈

堆栈在系统的进程里也是在VMA中处理的，在proc目录下对应进程号里，我们可以看到这种安排：
第一列是地址范围 ，第二列执行权限，第三列表示VMA对应的segment在镜像文件中的偏移，第四、五列是镜像文件所在的设备的主次设备号，第六列是VMA的segment名。

很明显栈[stack]在靠近内核的高地址，没有执行权限，堆[heap]靠近代码段的的低地址，这个和他们的增长方向有关。
[vdso]段在内核空间，进程可以通过访问这个地址和内核空间通信。

再来回顾一下虚拟空间（32bit）中，进程的执行视图，从上往下依次是：
[系统空间]：4G----3G
[栈] :靠近内核的高位地址，向下生长
[堆]:从低向高生长
[数据段]：
[代码段]：

内核装载ELF过程

1.bash调用fork()系统调用创建一个进程,然后该新进程调用execve()系统调用

2.execve系统调用的入口是sys_execve(),它负责参数的检查复制,完成后调用do_execve()

3.do_execve()读取文件的前128个字节,因为每种可执行文件的前128个字节的数据可以帮助我们知道则个文件是什么格式的,尤其是前4个字节(常常称之为魔数),比如ELF文件头的前四个字节就可以表示这是一个ELF格式的文件,这一步只负责读取128字节数据,不分析,然后调用search_binary_handle()
search_binary_handle(),根据128个字节,判断是什么文件格式,然后匹配合适的文件装载处理过程,其中,ELF文件的装载处理过程是load_elf_binary()

./fs/binfmt_elf.c:71: .load_binary = load_elf_binary,
./fs/binfmt_elf.c:556:static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)

4.load_elf_binary():

检查ELF可执行文件格式的有效性
寻找动态链接.interp段, 设置动态链接器路径
根据ELF文件头的内容,对ELF文件进行映射
初始化ELF进程环境：环境变量 参数列表等
将系统调用的返回地址修改成ELF可执行文件的入口地址(e_entry)
load_elf_binary()执行完毕,一路返回至sys_execve(),系统调用的返回地址已经改成了被装载的ELF文件的入口地址了,当执行完系统调用从内核态返回到用户态的时候,EIP寄存器直接跳转到了ELF程序的入口地址,装载完毕,然后就可以执行了

参考文章

https://blog.csdn.net/ordeder/article/details/41654509
《程序员的自我修养》