用GDB远程调试Linux内核

  从原始的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 , 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 = ”。执行“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许可证）