9.8 段错误，虚拟内存，内存映射 CSAPP

相信写代码的或多或少都会遇到段错误，segmentation fault. 今天终于看到这里面的底层原理

参考：

https://greenhathg.github.io/2022/05/18/CMU213-CSAPP-Virtual-Memory-Systems/18-Virtual-Memory-SystemsSimple memory system exampleAddress Translation Example #1 PPN实际不存在页表中 MMU做的第一件事是检查TLB，将VA中的VPN的TLBI(0x3)和TLBT(0x03)提取出来。所以会去查set3找到tag为3的line，找到对应的line并且valid为1，TLB将PPN(0D)返https://greenhathg.github.io/2022/05/18/CMU213-CSAPP-Virtual-Memory-Systems/

MMU接受到虚拟地址时候，触发缺页，异常会导致控制转移到内核的缺页处理程序，这个程序指向的步骤是：

- 这个虚拟地址VA合法吗？换句话说，这个地址在某个区域的区域内吗，为了回答这个问题，缺页处理程序会搜索区域结构的链表，把这个虚拟地址和区域结构的vm-start, vm-end比较，如果不合法，那么缺页处理程序就会触发一个段错误，从而终止这个进程。

- 试图进行的内存访问是否合法?换句话说，进程是否有读，写，执行这个区域内页面的权限？比如权限是只读的，你要进行写操作，或者用户模式进程要访问内核虚拟内存，这种情况会触发保护异常（没有权限）

- 正常缺页，这个缺页异常处理程序会选择一个牺牲也，交换页，调入新的页面，更新页表，使得MMU可以进行地址翻译

 这里不存在的页面是什么概念，就是unallocated的虚拟地址中的页面

内存映射

脑海里有这么一个图，有一列是disk, 有一列是物理内存，有一列是虚拟内存，彼此有一个映射关系，要么映射文件，要么映射匿名文件（全为0）， CPU请求内核创建的二进制零页，实际上没有数据传送，

共享对象，每个共享对象都有独一无二的名字，因此内核可以全局地看到各个进程对该共享对象的映射情况，比如进程1已经映射到某个物理空间上，那么进程2的页表PTE直接指向相应的物理页面。因此共享对象在物理内存中只有一份，它们在不同的进程中可以有不同的虚拟内存地址

私有对象，通过 写时复制（copy on write)技术，来尽量节省物理内存。一开始，物理内存只有一份，每个进程的虚拟内存的页表条目会标记为只读，带标记私有的写时复制。大家都没有进行写操作，那么就一份物理内存就够了，一旦某个进程对这个区域进行写操作，就会触发保护故障，故障处理程序会在物理内存中创建这个页面的一个新副本，执行写操作，更新进程1的虚拟内存页表条目指向这个新的页表副本。原则是不到万不得已就不复制物理内存上的副本。

 理解了私有对象如何映射到虚拟内存时，再来看看操作系统的fork函数，就很好理解了。原进程是进程1，有自己的虚拟内存，fork的时候，传教了一个新进程（新pid=2),　进程2直接复制进程1的mm_struct, vm_area_struct, page_table，然后两个进程的每个页面都标记为只读，并把区域结构vm_area都标记为私有写时复制COW。一旦这其中任意一个进程进行写操作，写时复制就会创建新的物理页面，因此也就为每个进程保持了私有地址空间的抽象概念。

 本质是copy延迟了，只有写时才复制。

再来看看execve函数，理解如何加载和执行函数。（filename, argvs, envp)

执行一个文件需要什么：

​​​​​​​

- binary file

- argements

- env_path : to find libraries