linux版本5.2.0-rc4
qemu-system-x86_64 -smp 4 -kernel bzImage -m 4096 -hda ~/stretch.img -serial stdio -append "earlyprintk=serial console=ttyS0 kgdboc=ttyS0 kgdbwait root=/dev/sda nokaslr" -enable-kvm -cpu host -s -S -display none
启动后效果如下:
图1
得到一个可以交互的kernel debug。这里是kdb的命令行,并不是kgdb的部分。后面会说明它们之间的关系。
此在在调试端按ctrl+ c 中断,看到此时kdb的栈回溯。
图2
图2看到kdb是从一个int3中断进入的。分析参数后发现是kgdbwait参数最后调用kgdb_breakpoint()也就是int 3的原因。
图3
从int3中断向上找关键函数。发现kgdb_cpu_enter()是kdb的入口。重启虚拟机对kgdb_cpu_enter()下断点。发现kgdb_cpu_enter()并不是中断一次
图4
这次是从nmi中断进入的。也就是还有代码给cpu发送了一个nmi导致。最后找到是kgdb_cpu_enter()发送的nmi中断。
图5
代码给了解释。原来是int3中断只能让一个核进入kdb。对于多核系统仅让一个核进入kdb其他核正常运行显然不合理,所以要让所有核都进入kdb。kgdb_cpu_enter()--->kdb_stub()--->kdb_main_loop()--->kdb_parse ()执行1054行对应每个命令的处理函数
图6
各个命令注册的处理函数如下
图7
上面是kdb的处理部分,常用的是用kgdb和gdb双机调试的方案。进入kgdb的代码
图8
kdb切换到kgdb需要一条命令
图9
为了能用从qemu动态抓到这个过程,需要修改qemu的启动参数。
图10
又增加了一个串口,第一个串口ttyS0用于打印内核启动流程,ttyS1用于在建立gdb和内核建立连接。所以除了用target remote localhost:1234 连接的调试还可以用 target remote /dev/pts/3连接。这样就可以从第一个gdb中看到第二个的连接过程和处理逻辑。
在第一个gdb对kdb_parse()下断点,然后第二个gdb开始连接
图11
第一个gdb此时断下来。.
图12
gdb发送正是kgdb命令,此时从kdb转换到kgdb。