x86/amd64下SIGTRAP的ucontext rip为何不指向触发的int3指令

这个行为是x86架构的硬件异常机制原生决定的，和Linux信号处理逻辑没有关系，本质是两类同步异常的触发时机完全不同：

• 故障（Fault）类异常：CPU在译码、执行指令的过程中，还没完成当前指令的操作就检测到错误，此时压入内核栈的异常返回地址就指向这条出错指令本身。等异常处理流程走完、执行iret返回用户态时，会回到这条出错指令重新尝试执行。你测试里ud2触发的SIGILL就属于这类：ud2是硬件强制规定的无效指令，CPU在译码阶段就会识别出错误，根本不会执行它，所以上下文里保存的rip直接指向ud2所在地址，从信号处理返回后会再次执行ud2、重复触发SIGILL，最后就coredump了。
• 陷阱（Trap）类异常：CPU会完整执行完当前触发异常的指令，才进入异常处理流程，此时压入栈的返回地址是紧接在陷阱指令之后的下一条指令地址，异常返回后直接从下一条指令继续跑，不会回头重复执行触发陷阱的指令。x86下int3触发的#BP断点异常（也就是SIGTRAP的硬件来源）就属于这类：int3是1字节长的专用断点指令，CPU执行完这条指令、rip已经自增到下一条指令位置后，才会抛出#BP异常，内核只是把硬件保存的rip值原封不动放到ucontext里，所以你看到的rip指向int3后面的ret，信号处理函数返回后直接执行ret回到main函数，才会打印出call returned。

架构差异说明 #

你观察到ARM/AArch64架构下bkpt #0/brk #0触发SIGTRAP时，上下文里的pc指向断点指令本身，同样是硬件设计决定的：ARM架构的断点指令属于故障类异常，硬件触发异常时并没有完成断点指令的执行，保存的返回地址就是断点指令自身的地址，内核只是如实透传硬件保存的寄存器值，不存在不同架构下信号处理逻辑双标的问题。

补充细节 #

你测试时看到SIGTRAP的si_addr为NULL也是符合架构规范的：x86的#BP异常硬件不会上报触发异常的指令地址，内核自然没法给si_addr填上有效地址；而#UD异常硬件会明确上报出错指令的地址，所以SIGILL的si_addr和上下文里的rip值完全一致。
这个硬件设计本身也贴合调试器的实际使用场景：gdb等工具用int3实现软件断点时，断点命中后会先把被替换成int3的原指令字节恢复，再手动把rip减1、回退到原指令的地址，才能让程序继续执行原本的指令。如果硬件默认把rip设为int3本身的地址，异常/信号处理返回后会立刻再次触发同一个断点，直接陷入无限死循环，反而需要调试器额外调整rip指向下一条指令，平白增加不必要的复杂度。

内容的提问来源于stack exchange，提问作者Sergio