如何阻止GDB因信号中断程序执行？——BOCHS调试场景

我之前也碰到过BOCHS和GDB交互时这种Signal 0的烦人事儿，咱们一步步来排查解决：

一、先搞懂Signal 0的本质 #

BOCHS里的Signal 0其实是它模拟的伪信号，不是系统原生的标准信号——毕竟系统里的信号编号从1才开始（比如SIGHUP是1），0是个特殊值，GDB默认对这种自定义伪信号的处理逻辑不兼容，这也是你用handle 0 nostop无效的核心原因。

二、针对性的解决方法 #

试试这几个方案，按顺序来：

1. 从源头切断信号发送 #

启动BOCHS时加上--disable-signals参数，直接让BOCHS停止向GDB发送这些自定义信号。比如你的启动命令可以改成：

bochs --dbg --disable-signals

这个方法最直接，能从根源解决信号干扰问题。

2. 调整GDB的信号处理规则 #

如果上面的方法不适用，试试在GDB里开启非停止模式，让GDB忽略目标程序的信号中断：

set non-stop on
handle all nostop pass

开启非停止模式后，GDB不会因为BOCHS发来的信号暂停，同时会把信号正常传递给BOCHS处理。

3. 检查BOCHS配置文件 #

打开你的bochsrc配置文件，看看有没有和信号相关的配置项：

• 如果有send_sigint=1，改成send_sigint=0，关闭不必要的信号通知
• 确认gdbstub相关配置没有开启多余的信号交互选项

三、进阶调试小技巧 #

如果还是没解决，你可以在GDB里用info signals命令查看所有信号的处理状态，确认BOCHS实际发送的信号类型（可能不是表面上的Signal 0）。另外，BOCHS自带的调试器本身功能也很全，你可以先在BOCHS内部定位页错误：

• 用info paging查看页表状态
• 用break *0xXXXX设置硬件断点定位错误地址
  先搞定页错误的根源，再结合GDB调试内核代码，能避开不少信号干扰。

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