从原始的printk方法到Kprobes、SystemTap等错误跟踪技术，Linux内核为我们提供了不少的手段来调试内核。不过，开发过程中最自然的调试方式还是源码级调试，就如用GDB调试应用程序那样，可以下断点、单步、查看变量等。其实Linux内核也提供了源码级调试工具——KGDB。下面介绍一下KGDB的原理以及具体的配置使用方法。
1、KGDB的调试原理
“内核的KGDB调试特性，实现了命令处理、陷阱处理及串口通信等功能，用以支持GDB远程调试内核。KGDB特性在Linux内核中添加了一个调试Stub。调试Stub是Linux内核中的一小段代码，提供了运行GDB的开发机和所调试内核之间的一个媒介。GDB和调试Stub之间通过GDB串行协议进行通讯。GDB串行协议是一种基于消息的ASCII码协议，包含了各种调试命令。当设置断点时，KGDB负责在设置断点的指令前增加一条trap指令，当执行到断点时控制权就转移到调试Stub中去。此时，调试Stub的任务就是使用远程串行通信协议将当前环境传送给GDB，然后从GDB处接受命令。GDB命令告诉Stub下一步该做什么，当Stub收到继续执行的命令时，将恢复程序的运行环境，把对CPU的控制权重新交还给内核。[1]”
2、KGDB+GDB远程调试环境配置
开发机：CentOS 7 x86_64，工作目录：~/workspace
目标机：Qemu虚拟机 + linux-3.10.107 kernel + busybox
2.1、开发机 CentOS 7 x86_64 基础配置
① 安装EPEL扩展源
$ sudo yum install epel-release
② 更新系统到最新状态
$ sudo yum update
③ 安装 Xfce 桌面环境<1>
$ sudo yum groupinstall "X Window system"
$ sudo yum groupinstall "Xfce"
$ sudo set-default graphical.target
$ sudo reboot
2.2、Linux 内核编译
① 安装编译内核所需工具
$ sudo yum install wget ncurses ncurses-devel gcc bc
② 获取内核源码<2>
$ cd ~/workspace
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.10.107.tar.xz
$ tar -xJvf linux-3.10.107.tar.xz
③ 配置内核<3>[4]
$ cd linux-3.10.107
$ make defconfig
$ make menuconfig
Kernel hacking --->
[*] Compile the kernel with debug info
[*] Compile the kernel with frame pointers
[*] KGDB: kernel debugger --->
<*> KGDB: use kgdb over the serial console
[ ] Write protect kernel read-only data structures
Device Drivers --->
< > Sound card support
--->
[ ] USB support --->
Security options --->
[ ] NSA SELinux Support
④ 编译内核
$ make -j2
2.3、制作busybox根文件系统
① 获取busybox源码
$ cd ~/workspace
$ wget http://busybox.net/downloads/busybox-1.27.2.tar.bz2
$ tar -zjvf busybox-1.27.2.tar.bz2
② 配置busybox
$ cd busybox-1.27.2
$ make menuconfig
“
Busybox Settings --->
--- Build Options
[*] Build BusyBox as a static binary (no shared libs)
Miscellaneous Utilities --->
[ ] flashcp
[ ] flash_eraseall
[ ] flash_lock
[ ] flash_unlock
”
③ 编译安装busybox
$ sudo yum install glibc-static
$ make
$ make install
④ 制作根文件系统
$ dd if=/dev/zero of=./busybox.img bs=1M count=100
$ mkfs.ext3 busybox.img
$ mkdir /tmp/disk
$ sudo mount -o loop busybox.img /tmp/disk
$ sudo cp -rf _install.* /tmp/disk
$ cd /tmp/disk
$ sudu mkdir dev sys proc etc lib mnt
$ sudo cp -a ~/workspace/busybox-1.27.2/examples/bootfloppy/etc/* etc
$ sudo vi etc/init.d/rcS
“
#! /bin/sh
/bin/mount -a
/bin/mount -t sysfs sysfs /sys
/bin/mount -t tmpfs tmpfs /dev
/sbin/mdev -s
”
$ cd ~/workspace
$ sudo umount /tmp/disk
2.4、Qemu 虚拟化环境安装
$ sudo yum install qemu
2.5、启动KGDB+GDB调试内核
$ cd ~/workspace
① 安装gdb
$ sudo yum install gdb
② 启动Qemu<4><5>
$ qemu-system-x86_64 -kernel linux-3.10.107/arch/x86/boot/bzImage -append "root=/dev/sda kgdboc=ttyS0,115200 kgdbwait" -boot c -hda busybox-1.27.2/busybox.img -k en-us -serial tcp::4321,server
终端界面出现“QEMU waiting for connection on: tcp:0.0.0.0:4321,server”
③ GDB远程连接目标机<6><7>
$ cd ~/workspace
$ gdb
(gdb) file linux-3.10.107/vmlinux
Reading symbols from /home/yeyuzhen/workspace/linux-3.10.107/vmlinux...done.
(gdb) target remote:4321
Remote debugging using :4321
kgdb_breakpoint () at kernel/debug/debug_core.c:1014
1014 wmb(); /* Sync point after breakpoint */
(gdb) b sys_sendto
Breakpoint 1 at 0xffffffff815b44d0: file net/socket.c, line 1754.
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0xffffffff815b44d0 in SyS_sendto at net/socket.c:1754
(gdb) c
Continuing.
[New Thread 850]
[Switching to Thread 850]
Breakpoint 1, SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688, addr_len=28) at net/socket.c:1754
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
(gdb) list
1749 * Send a datagram to a given address. We move the address into kernel
1750 * space and check the user space data area is readable before invoking
1751 * the protocol.
1752 */
1753
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
1755 unsigned int, flags, struct sockaddr __user *, addr,
1756 int, addr_len)
1757 {
1758 struct socket *sock;
(gdb) n
schedule () at kernel/sched/core.c:3092
3092 {
(gdb)
3093 struct task_struct *tsk = current;
(gdb)
3095 sched_submit_work(tsk);
(gdb)
3092 {
QEMU虚拟机性能较差，主要就是研究Linux内核源码使用。在使用物理机或者VMware虚拟机的环境中配置KGDB+GDB远程调试，主要有两方面不同：
① 目标机的Linux内核最好在目标机上编译，并直接替换目标机内核；
② KGDB和GDB之间串口通讯的配置方式不同，具体可以参考网络上的相关博文。
3、实际调试过程中遇到的典型问题的解决方法
3.1、在断点处停下后，在GDB执行“next”下一语句指令，执行流会被系统调度线程抢占，无法持续跟踪当前执行流。
[New Thread 850]
[Switching to Thread 850]
Breakpoint 1, SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688, addr_len=28) at net/socket.c:1754
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
(gdb) list
1749 * Send a datagram to a given address. We move the address into kernel
1750 * space and check the user space data area is readable before invoking
1751 * the protocol.
1752 */
1753
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
1755 unsigned int, flags, struct sockaddr __user *, addr,
1756 int, addr_len)
1757 {
1758 struct socket *sock;
(gdb) n ==> 前面是断在sys_sendto函数入口的，执行next之后就被调度线程抢占了。
schedule () at kernel/sched/core.c:3092
3092 {
(gdb)
3093 struct task_struct *tsk = current;
(gdb)
3095 sched_submit_work(tsk);
(gdb)
3092 {
linux内核其实算是一个多线程执行的程序，内部有很多的线程。我们用“info thread”可以看到很多线程信息，
(gdb) info thread
[New Thread 4294967294]
[New Thread 2]
[New Thread 3]
…… ……
[New Thread 757]
[New Thread 758]
Id Target Id Frame
40 Thread 758 (init) 0x0000000000000000 in irq_stack_union ()
39 Thread 757 (sh) 0x0000000000000000 in irq_stack_union ()
…… ……
4 Thread 2 (kthreadd) 0x0000000000000000 in irq_stack_union ()
3 Thread 4294967294 (shadowCPU0) SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688,
addr_len=28) at net/socket.c:1754
* 2 Thread 761 (ping) SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688, addr_len=28)
at net/socket.c:1754
1 Thread 1 (init) 0x0000000000000000 in irq_stack_union ()
查了一下GDB的帮助文档[5]，GDB有个针对多线程执行机制的调试命令“scheduler-locking”。默认是“step”模式，如下：
(gdb) show scheduler-locking
Mode for locking scheduler during execution is "step".
按官方的解释，就是在“step”模式下执行“step”下一指令，可以保证当前的线程不会被抢占，因为其它线程不会执行。而除了“step”以外的指令，如“continue”、“until”和“finish”会导致其它线程重新开始执行。所以，默认模式下，我们用“step”来调试“sys_sendto”应该就不会被调度线程抢占了。
[New Thread 762]
[Switching to Thread 762]
Breakpoint 1, SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688, addr_len=28) at net/socket.c:1754
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
(gdb) list
1749 * Send a datagram to a given address. We move the address into kernel
1750 * space and check the user space data area is readable before invoking
1751 * the protocol.
1752 */
1753
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
1755 unsigned int, flags, struct sockaddr __user *, addr,
1756 int, addr_len)
1757 {
1758 struct socket *sock;
(gdb) step => 继续sys_sendto的执行，没有被抢占
SYSC_sendto (fd=0, buff=0x40 <irq_stack_union+64>, len=64, flags=0, addr=0x8766d8, addr_len=28)
at net/socket.c:1767
1767 sock = sockfd_lookup_light(fd, &err, &fput_needed);
后续，我还试了“step”进入函数“sockfd_lookup_light”，然后“finish”出来，也是可以回到“sys_sendto”线程的。
“scheduler-locking”总共有三种模式on、off、step。“step”模式的效果前面试过，就不赘述。“off”模式比较好理解，就是放开线程调度，当前线程以外的线程可以自由执行。而“on”模式，官方的解释是可以让除当前线程以外的线程完全停止调度。理论上就可以用“next”指令调试当前线程了。可是，设置成“on”模式调试“sys_sendto”函数，还是会被调度线程抢占，估计是KGDB+GDB调试的一个Bug吧。
kgdb_breakpoint () at kernel/debug/debug_core.c:1014
1014 wmb(); /* Sync point after breakpoint */
(gdb) show scheduler-locking
Mode for locking scheduler during execution is "step".
(gdb) set scheduler-locking on => 设置为“on”模式
(gdb) show scheduler-locking
Mode for locking scheduler during execution is "on".
(gdb) b sys_sendto
Breakpoint 1 at 0xffffffff814f3d70: file net/socket.c, line 1754.
(gdb) c
Continuing.
[New Thread 762]
[Switching to Thread 762]
Breakpoint 1, SyS_sendto (fd=0, buff=64, len=64, flags=0, addr=8873688, addr_len=28) at net/socket.c:1754
1754 SYSCALL_DEFINE6(sendto, int, fd, void __user *, buff, size_t, len,
(gdb) show scheduler-locking
Mode for locking scheduler during execution is "on".
(gdb) n => 还是被调度程序抢占
schedule () at kernel/sched/core.c:3092
3092 {
(gdb) list
3087 if (blk_needs_flush_plug(tsk))
3088 blk_schedule_flush_plug(tsk);
3089 }
3090
3091 asmlinkage void __sched schedule(void)
3092 {
3093 struct task_struct *tsk = current;
3094
3095 sched_submit_work(tsk);
3096 __schedule();
下一步工作：
通过上面的配置，已经可以进行Linux内核的调试了。不过，调试过程中还遇到不少影响调试的问题：
① KGDB停在“kgdb_breakpoint () at kernel/debug/debug_core.c:1014 wmb(); /* Sync point after breakpoint */”时，给“start_kernel”下断点是无效的。“kgdb_breakpoint ()”应该是在“start_kernel”之后了。本来qemu启动参数可以加“-S”参数，让虚拟机一启动就停下来。可是使用这个选项后，GDB会提示Bug“Remote 'g' packet reply is too long”，GDB和系统都卡死。
② 在GDB启动的时候，我们载入了vmlinux内核调试符号表，直接编译到内核的部分都可以调试了。可是，很多功能是做成独立模块的，需要用特定的方式载入独立模块的调试符号表，才能对模块的功能进行调试。
③ 要调试内核协议栈的话，需要让busybox开启网路功能。
④ 编译内核时默认的编译优化级别会导致GDB无法查看被优化的变量，显示“$n = <optimized out>”。执行“bt”查看调用栈的时候，也显示不完全，会出现“#n 0x0000000000xxxxxx in ?? ()”。
这些问题的解决方法，后续会继续更新在这里。
注解
<1> 在开发机上安装"X Windows system"、"Xfce"，是因为Qemu需要图形环境才能运行。而且，一定要按顺序安装这两个东西，否则Qemu启动的时候会出现无故卡在tty初始化的地方。
<2> 选择linux-3.10.x最新版是因为，现在CentOS最新版为7，是基于linux-3.10.x内核的。这样就保证我们研究的内核版本是当前业界最广泛使用的版本。
<3> 选项“CONFIG_DEBUG_RODATA”，需要取消勾选。因为勾选的话，会导致KGDB操作断点的时候报“KGDB: BP remove failed xxx”，系统直接卡死。
<4> 记得是去Xfce桌面环境的Terminal上启动Qemu，用SSH连接+X11转发启动Qemu可能会卡住。因为我的开发机CentOS7是跑在VMware Workstation上的，不知道是不是环境问题。
<5> STAT硬盘接口用“root=/dev/sda”，IDE硬盘接口用“root=/dev/hda”。不确定硬盘接口类型，如果启动出错就换一种试试。
<6> 在busybox的命令行中输入“ping 127.0.0.1”，就会调用UDP的sys_sendto系统调用。
<7> 在调试sys_sendto过程中，内核进行了进程切换。比较影响调试操作，据说需要修改GDB多线程调试配置。
参考
[1] Linux系统内核的调试，李树雷
[2] 使用KGDB调试内核 on QEMU(一步一步跟我学)，DDD
[3] 请教几个KGDB调试遇到的问题，dedodong
[4] How to compile the linux without any audio codecs?，Mark
[5] Debugging with GDB - 5.5.1 All-Stop Mode，Free Software Foundation,Inc
修订记录
2017-11-03 PM：增加避免当前线程被抢占的方法；
2017-11-01 PM：从网易博客迁移到简书；
2017-10-26 AM：完成初稿；
版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
