GDB调试中进程突发SIGSEGV且寄存器指令正常时如何排查原因

首先明确核心前提：subs r2,r2,r2是ARM架构下的通用寄存器运算指令，功能是将r2寄存器的值置0，同时更新程序状态寄存器的标志位，整个执行过程不涉及任何内存读写访问，从指令语义上完全不可能直接触发段错误。出现当前指令和段错误触发点不匹配的情况，本质是调试过程中的上下文错位，可按以下步骤逐一定位：

• 核实信号触发的真实现场信息
  • 运行GDB命令info signals SIGSEGV，确认段错误信号的上报配置，排除人为手动发送信号的异常情况
  • 运行print $_siginfo查看信号完整元数据，重点记录si_addr字段值，确认非法内存访问的目标地址，以及异常类型是取指错误、数据读错误还是数据写错误
  • 运行info threads确认当前附着的调试线程，排查是否存在多线程并发切换导致的GDB帧错位——即当前显示subs r2,r2,r2指令的线程，根本不是触发段错误的线程
• 回溯真实的异常指令位置
  段错误属于硬件同步异常，内核会在异常触发后将信号上报到用户态，天然存在一定的上下文偏移：
  • 查看当前PC值附近的指令段，执行x/30i $pc - 0x80，向前回溯128字节范围内的所有指令，找到距离当前位置最近的访存类指令（ldr/str类加载存储指令），这类指令才有可能触发MMU权限检查失败
  • 重点核查libc信号处理入口的指令特征：多数C库在进入用户态信号处理函数时，会先执行一段寄存器初始化逻辑，这段逻辑里就包含大量subs r2,r2,r2这类清零寄存器的指令。这种情况下GDB当前停住的位置，已经是段错误发生后、进入信号处理流程的位置，不是真正的错误现场
• 排查常见的错位触发场景
  • 执行bt full检查完整调用栈，确认栈帧是否存在损坏：如果之前发生栈溢出破坏了函数返回地址，会导致程序跳转到非法地址执行，在内核触发段错误、切换到信号处理上下文后，才会执行到当前的subs r2,r2,r2
  • 检查协处理器、MMU权限相关的异常：比如未开启浮点访问权限、访问了受保护的内核内存区域，这类异常触发的SIGSEGV，同样会经过内核的信号上报流程，造成调试时的指令位置错位

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