对内核进行调试一直个比较麻烦的事情，最近需要研究内核的IO行为，又让我萌生单步跟踪调试的念头。刚好了解到qemu的-gdb选项，然而用起来也不是像傻瓜相机那样简单，还是有一些步骤要做的。另外网上这方面资料也还比较少。

1. 编译debug版本内核

标准的发行版内核是没有debug信息的，需要编译新的内核。下载内核后，在`make menuconfig`这一步，把kernel debugging选项打开, 以及其他几个相关选项。

【Kernel hacking】
     -*- Kernel debugging
     [*] Allow gcc to uninline functions marked 'inline'
     [*] Debug low-level entry code
     Choose kernel unwinder
         (X) Frame pointer unwinder

配置后对内核make，成功完成后，应该在内核目录下看到` arch/x86_64/boot/bzImage`这个文件。

除此之外，我还手工修改Makefile，给`KBUILD_HOSTCFLAGS`, `KBUILD_HOSTCXXFLAGS`, `KBUILD_CFLAGS`都增加了-g选项。

另外还尝试了把-O2选项改成-O0, 但是这个行不通，编译根本无法通过。

2. 启动qemu

这里要注意下qemu的版本，太旧版本的qemu不工作，vm能启动，但是gdb调试时会报告 “Remote 'g' packet reply is too long:” 这样的错误。从实践看，换到qemu 3.1.0版本是可以工作的。顺便一提的是，为了快速从源代码编译qemu, 减少依赖项，编译qemu时可以尽量少带些功能。可以用这样的configure命令来配置qemu：

qemu# ./configure --target-list=x86_64-softmmu --disable-werror --disable-rbd --disable-bluez --disable-brlapi
qemu# make

编译后用如下命令启动qemu:

# /root/qemu3.1.0/x86_64-softmmu/qemu-system-x86_64 -vnc :2  -S -s -kernel arch/x86_64/boot/bzImage -append nokaslr

这里的几个参数是这样的

-vnc :2， 打开一个vnc，这样可以通过vncviewer访问 localhost:2看到VM的控制台
-S 表示启动后就挂起，等待gdb连接
-s 是-gdb :1234的缩小，就是打开1234这个gdb调试端口
-kernel 指定要启动加载的kernel文件
-append nokaslr是传递给内核的参数。表示禁用kaslr(Kernel Address Space Layout Randomization) 。

最后这个kaslr很关键，否则话kernel加载到内存后他的地址会进行随机化，这样gdb任务的地址和kernel实际的加载地址就不一致，会导致断点完全不工作。我没少耗费时间在这个坑里。

3. 启动gdb进行调试

在gdb进行调试前，在~/.gdbinit 里增加这样一行
add-auto-load-safe-path /path-to-you-new-kernel-dir

gdb会从kernel目录下面加载脚本。这个目录下面有个vmlinux-gdb.py 文件。

gdb -ex "file /z0/liulele/workspace/kernel-nvf/nvme/vmlinux" -ex "target remote :1234"
(gdb) break start_kernel
(gdb) c

这时就可以看到内核中断在start_kernel函数上。可以查看变量，可以单步跟踪。

到这里调试步骤基本通了。然而这样运行起来的不是要给完整的linux系统，打开vnc会看到linux无法继续运行，会报告“Unable to mount rootfs"。也可以给qemu启动时指定一个rootfs，然而我更喜欢把内核安装到guest OS系统里面，启动完整的linux.

安装内核的方法网上比较多了，就是" make bzImage; make modules; make install; make modules_install"这几步。需要提示的几个技巧是：

1. 在guest系统里面做内核编译。为此启动qemu时可以-enable-kvm -smp 8，把硬件加速和多核功能都启用起来。调试时启动qemu不要带这个参数。
2. kernel source code放到Host系统，然后guest通过nfs访问host系统里的source code，且让source code在host和guest系统里的目录路径相同。即nfs挂载时也挂载到和host系统相同的目录下。这样guest系统编译用到的路径，和host系统gdb用到的路径就一致了
3. 修改guest系统的 /boot/grub/grub.cfg, 给准备使用的新linux 内核增加 nokaslr 参数

这样就可以调试完整的linux系统了。

最后安利个gdb神器 -- cgdb. cgdb可以更方便的看代码，设置断点。其实我更习惯用visual studio，但是还没找到用visual studio 2017连接remote gdb 的方法。