GDB 调试内核模块

1 利用virt-manager创建需要虚拟机

2 更换虚拟机的内核到需要调试的内核.

3 virsh edit 更改虚拟机配置，使其支持调试

注意 只加-s 参数即可。
Qemu arg

4 拷贝虚拟机里的编译好的内核到宿主机，并进入 gdb 调试

scp -r linux-4.18.20 [email protected]:~
gdb vmlinux
target remote 127.0.0.1:1234

5 在 do_init_module 添加断点并继续执行。

b do_init_module
c

6 在虚拟机上插入需要调试的模块：

insmod progger_trace.ko

7 gdb 里打印 text section，data section 和 bss section 的名称和地址：

 print mod->sect_attrs->attrs[1]->name 
 print mod->sect_attrs->attrs[7]->name 
 print mod->sect_attrs->attrs[9]->name 
 print /x mod->sect_attrs->attrs[1]->address 
 print /x mod->sect_attrs->attrs[7]->address 
 print /x mod->sect_attrs->attrs[9]->address

8 根据上面打印的地址导入编译好的内核模块

add-symbol-file /root/progger/linux_progger/progger_trace.ko  -s .data  -s .bss 

9 下面就可以在模块代码中添加断点并单步调试了：

编译内核

yum groupinstall "Development Tools"
make menuconfig
make -j 4
make modules
make modules_install
sudo make install

错误:

Remote 'g' packet reply is too long 错误的原因
这个错误是当目标程序执行时发生模式切换（real mode 16bit -> protected mode 32bit -> long mode 64bit）的时候，gdb server（此处就是 qemu）发送了不同长度的信息，gdb 无法正确的处理这种情况，所以直接就报错。 此时需要断开连接并切换 gdb 的 arch （i386:x86-64 和 i386:x86-64:intel ），arch 变化后，gdb 会重新设置缓冲区，然后再连接上去就能正常调试。这个方法规避了一些麻烦，但是实际上有两种正规的解决方案：
（1） 修改 gdb 的源码，使 gdb 支持这种长度变化（gdb 开发者似乎认为这个问题应该由 gdb server 解决）.
（2） 修改 qemu 的 gdb server，始终发送 64bit 的消息（但是这种方式可能导致无法调试 real mode 的代码）

解决方法:

1 修改gdb代码，打patch。
2 # 断开 gdb 的连接
  disconnect
  # 重新设置 arch
  # 此处设置和之前 show arch 的要不一样
  # 之前是  i386:x86-64 于是改成  i386:x86-64:intel
  set arch i386:x86-64:intel

cannot access memory 解决方法主要看4
因为内核启用这项特性之后，内核启动时会随机化内核的各个 section 的虚拟地址（VA），导致 gdb 断点设置在错误的虚拟地址上，内核执行时就不会触发这些断点。

可以更改/etc/grub2.conf 添加 nokasrl 命令参数。
然后`grub2-mkconfig -o /boot/grub2/grub.cfg`

或者取消 Processor type and features -> Build a relocatable kernel 
取消后 Build a relocatable kernel 的子项 Randomize the address of the kernel image (KASLR) 也会一并被取消

参考:
1 https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2016/06/21/gdb-linux-kernel-by-qemu
2 https://linux.cn/article-9665-1.html
3 https://imkira.com/a21.html
4 https://stackoverflow.com/questions/44612822/why-gdb-cannot-find-the-source-lines-of-the-linux-kernel-when-debugging-through