使用GDB与QEMU调试内核时的问题分析

使用QEMU+GDB能够实现源代码级的内核调试，但是，存在一个问题──当内核允许中断时，单步命令（n与s）会进入时钟中断。通过浏览QEMU的源代码，大体把原因找了出来。 单步命令（n与s）在gdb远程调试通讯协议中是s（参看info gdb），qemu的gdb stub在受到s命令后将虚拟CPU进入单步状态，但是在接收到s命令前，qemu的虚拟CPU是停止的（在等待gdb的命令），注意，这个时候，虚拟时钟计时并没有停止，所以，很可能在qemu的虚拟CPU还没开始的时候就需要触发时钟中断了，但是虚拟CPU还在停止状态，中断无法触发。接收到s命令后，虚拟CPU开始执行指令。这时，如果内核允许中断，虚拟时钟就将触发中断，所以s命令执行一条指令后停止在时钟中断处理程序的开始处，而不是希望的函数中下一条指令处。

现在看一下问题的解决方法。在我看来，需要修改gdb远程调试内核时单步命令的语义。有两个方向。

1.在gdb上修改。在处理用户的n与s命令时不是发送协议中的s命令，而是分两步。首先确定下一条指令的开始位置（或者下一行源程序对应的指令的开始位置）。对于有些RISC机器机器指令固定为某个长度，那么确定这个位置比较简单，但是对于像x86这样的变长指令的体系结构就需要稍微麻烦一点（需要确定当前指令的长度等）。然后假如第一步确定的地址是naddr。现在像处理用户的tbreak *naddr一样处理就可以了，接着发送继续运行命令c就可以了。

2.在qemu的gdb stub上修改协议命令s的处理方法。接收到s命令后不是让虚拟CPU进入单步执行状态，而是确定在没有中断的情况下，下一条指令的位置（注意对于当前是跳转指令的情况处理比较复杂），然后在这个位置设置临时断点，在虚拟CPU到达这个断点进入gdb stub后立即将其取消。

这两种处理方法中，我认为1比较好，实现起来清晰明了，但是需要对gdb的代码比较熟悉。2方法比较复杂，尤其是在当前指令是跳转指令时，不太容易确定临时断点的位置。另外作为暂时的权宜之计，我们可以只使用tbreak +offset来代替n与s命令。