[Linux] 信号(singal)详解(二):信号管理的三张表、如何使用coredump文件、OS的用户态和内核态、如何理解系统调用？
标题：[Linux] 信号管理的三张表、如何使用coredump文件、OS的用户态和内核态、如何理解系统调用？
@水墨不写bug
（图片来源：文心一言）
正文开始：
目录
一、信号管理的三张表
（1）三张表
（2）信号三张表实际意义的实例
（3）信号阻塞和忽略的区别
（4）signal捕捉信号的本质
二、coredump文件如何使用？
三、OS的用户态和内核态
四、如何理解系统调用？
1. 系统调用的作用
2. 系统调用的触发方式
3. 系统调用的执行流程
一、信号管理的三张表
（1）三张表
i、block位图（32位）
比特位的位置：代表信号的编号
比特位的内容：表示信号是否被阻塞：1表示对应的信号被阻塞，0表示对应的信号没有被阻塞。
ii、pending位图（32位）
比特位的位置：表示信号的编号
比特位的内容：表示信号是否收到：1表示信号被收到，但是还没有递达（处于未决状态），0表示信号没有处于未决状态。
iii、hander表
hander表本质上不是位图，而是一张函数指针表，存有函数地址。
表内数据的位置：表示信号的标号
表内数据的内容：表示对应要调用的函数地址
这三张表，是OS管理信号的根本依靠，他们实现了让OS通过两张位图+一张函数指针数组让OS内的进程可以识别信号！！
（2）信号三张表实际意义的实例
举一个例子，具体来说，根据上面这个图的三张表表示的信号状态而言：
1号信号：pending对应为0，表示没有产生过1好信号；block是0，表示1号信号没有被阻塞（1号信号一旦产生，就会被递达，在这之间可能会存在短暂的pending状态，但是这段时间非常短）。1号信号的函数指针数组存储为：SIG_DFL，表示按照默认的信号处理方式处理1号信号。
2号信号：pending对应为1，表示产生了2号信号，但是同时block为1，表示2号信号被阻塞，所以产生的2号信号一直处于pending状态，而不会被递达。2号信号的函数指针数组存储为：SIG_IGN，表示处理方式是忽略2号信号。
3号信号：pending为0，表示还没有捕捉到3号信号，3号信号的block为1，表示如果出现3号信号，3号信号会被阻塞而不递达。3号信号的处理方式是用户自定义处理的函数sighandler函数。
（3）信号阻塞和忽略的区别
信号阻塞：是对信号是否递达的处理；
信号忽略：是信号递达后的一种处理动作。
被阻塞的信号产生时保持在未决状态，直到进程解除对这个信号的阻塞，然后才执行递达动作。
阻塞和忽略不同，只要信号被阻塞就不会递达；忽略是信号被递达后采取的一种处理动作。
（4）signal捕捉信号的本质
把用户提供的函数指针填入到对应的handler表中。
某些信号无法被捕捉、忽略、阻塞——SIGKILL（9号信号）、SIGSTOP（19号信号）
二、coredump文件如何使用？
其实这是一个以前就遇到过的问题：
信号的默认处理方式的core和term都是终止进程，这两种信号终止进程有什么不同？
tem: 本质就是异常终止了进程；
core：也是异常终止了进程；但是进程退出的时候（发生错误的时候）的镜像数据会被核心转储，最终会生成一个Debug文件，这个文件可以被调试器（比如cgbd使用）后面会进行讲解。
注意：
1.默认coredump被关闭。
在旧版本的CentOS上，每一次生成的code文件的名字都是不同的，当大项目出错时，一般服务器会快速重启，若重复出错，会生成很多的core大文件，如果这样的错误是在晚上发生的，那么累计一晚上的core文件占用的空间很可能会让服务器爆盘，从而无法再启动服务器。
2.如何打开codedump？
指令：
ulimit -c 10240
表示允许生成的最大文件占用的块数为10240。当进程被信号杀掉后，会生成一个core文件。同时把返回的标志的第7位置1（coredump标志，这个标志表示是否形成了core文件）。
如何使用core文件？（以cgbd为例）
当一个进程报错后，会产生core文件，我们可以打开cgbd来调试这个程序。
打开gbd对指定的程序调试
指令：
core -file + core文件名
运行这条指令可以直接加载进程在崩溃时的错误信息，这样就可以直接定位出错的位置，同时可以直接查看出错时的各个变量的值，免去了找错的过程！
三、OS的用户态和内核态
OS在执行我们写的代码的时候，会进行内核态和用户态的转变；
在收到一个信号的时候，对应的信号的位置被置1，但是信号不会被立刻处理，而是在进程丛内核态将要返回用户态的时候，进行处理，具体过程如下：
具体过程如下：
1.执行主流程收到某一信号；
2.进入内核处理异常之后，在回到用户态之前，处理进程中可以递达的信号。
3.如果这个信号的处理动作是用户自己定义的函数，则OS会回到用户态，直接进入用户自定义函数的逻辑处（这里注意不是回到主流程！）。
4.处理完用户自定义函数之后，调用特殊系统调用sigreturn返回内核态。
5.返回用户态，然后回到主流程继续处理。直到再次检测到异常重复上述操作。
总结来说，进行信号的检测和处理的阶段是在：进程从内核态返回用户态之前。
对于内核态和用户态的地址空间的理解： （以32位机器为例）
1.OS通过内核级页表找到内核空间；通过用户级页表找到用户空间。2.OS本身就在进程的地址空间中；
3.不同进程对应不同份的用户级页表；对应同一份内核级页表——内核级页表只有一份，无论你进程如何切换，总能找到OS。
4.用户访问OS，其实还是在地址空间当中进行的！这个过程和访问函数是一样的。
5.但是用户访问OS只能通过一个方式：系统调用。
四、如何理解系统调用？
在Linux系统中，系统调用（System Call）是用户空间程序与内核之间进行交互的核心机制。
首先需要理解：
操作系统OS本质就是一个死循环 + 时钟中断 来不断调用系统的任务的。
1. 系统调用的作用
桥梁作用：允许用户程序请求内核执行特权操作（如文件操作、进程管理、网络通信等）。
安全隔离：用户程序无法直接访问硬件或内核资源，必须通过系统调用委托内核完成，确保系统安全和稳定。
2. 系统调用的触发方式
软中断或专用指令：
传统方式：通过
int 0x80（x86）触发软中断。现代方式：使用更高效的
syscall/sysenter指令（x86_64）或svc（ARM）。内核入口：触发后，CPU切换到内核态，跳转到预设的中断处理程序（如
entry_SYSCALL_64）。
3. 系统调用的执行流程
1.OS在启动时，会初始化一张函数指针数组，这个函数指针数组就是系统调用表（sys_call_table），OS要调用系统调用，只需要找到特定的函数指针数组下标，就能执行对应的系统调用。
2.在OS的中断向量表中，同样有“执行任意系统调用”的方法。
实例：
1.在调用fork（）「父进程创建一个子进程」的时候，OS会把sys_fork的系统调用号存入寄存器，同时向CPU执行进入系统的（int ox80）中断，于是CPU据此形成中断号，并根据中断号索引到“执行任意系统调用”的方法。然后传入系统调用号，在sys_call_table中索引执行系统调用。
已知OS不相信任何用户，OS如何做到阻止用户直接访问内核空间？
1、CPU中有一个特殊的寄存器CS（Code Semgment）寄存器，这个寄存器存储的是当前执行的代码的地址范围。寄存器的低二位的状态则代表了当前OS所处的状态：
如果低二位为0——内核态
如果低二位为3——用户态
总结：
对用户空间，CPU会根据得到的虚拟地址通过页表转换访问物理地址。当CPU拿到的虚拟地址是[3,4]GB的内核空间的时候，CPU会检测到CS寄存器低二位是否是0（内核态），如果不是，则CPU拦截非法访问，如果是，则可以访问内核空间数据。
完~