1. 为什么我要从零搭一套内核调试环境搞内核开发的人迟早会撞上Kernel panic。那种屏幕上刷出一大片调用栈、寄存器快照、Call Trace然后系统直接僵死的场面第一次见会懵见多了反而会兴奋——因为 panic 本身就是内核给你留下的案发现场。问题在于很多人根本没有一个能稳定复现 panic、能挂 gdb、能随时重启的沙盒环境只能在一台真机上反复折腾重启一次等三分钟调一次崩一次效率低到让人想砸键盘。这套环境的核心目标就一句话让内核 panic 变成一件可控、可复现、可单步调试的日常操作。我用的组合是 QEMU GDB 一份自己编译的 Linux 内核跑在 Ubuntu 上全程命令行不依赖任何图形化 IDE 也能干活想接 VSCode 也随时能接。整套东西搭下来大概半小时之后你就能做到改一行内核代码、重新编译、启动虚拟机、触发 panic、gdb 断在出错的那一行、看寄存器看栈、改完再来一遍。这个循环跑顺了内核调试才真正开始变得好玩。这篇文章适合谁如果你写过 C、用过 Linux、听说过 gdb 但没怎么用过那就能跟上。如果你已经能熟练编译内核那可以重点看第 3 节的 QEMU 参数和第 4 节的 gdb 脚本那些是我踩过坑之后沉淀下来的配置。整篇内容我会把为什么这么选讲清楚而不是甩一堆命令让你抄——因为内核调试这活儿抄命令只能抄到皮毛理解参数背后的意图才能举一反三。先说清楚这套环境解决的核心痛点真机调试内核崩溃即失联没有串口或者串口配置不对你连 panic 信息都抓不全而 QEMU 模拟出来的机器panic 了进程还在gdb 随时能 attach日志随时能存盘还能加-s -S让内核在第一条指令就停下来等你。这就是随时能 panic的底气所在。2. 环境整体设计与选型思路2.1 为什么是 QEMU 而不是真机或其它模拟器内核调试环境的第一决策是跑在哪。真机最真实但代价是崩溃后无法观测、无法单步、无法快速重置纯软件模拟器里QEMU 是生态最成熟、对 Linux 内核支持最好的一个。它支持 KVM 加速在 x86 宿主机上跑 x86 客户机可以接近原生速度编译一次内核几分钟就能启动验证这个迭代速度是真机比不了的。有人会问为什么不直接用 Docker 或者用户态模拟。Docker 共享宿主机内核你根本没法调试内核本身用户态模拟比如 UML虽然能跑内核但对硬件行为的模拟太简化很多和内存管理、中断相关的 panic 复现不出来。QEMU 的好处是它模拟了一整套虚拟硬件CPU、内存、磁盘、网卡、串口内核跑在上面和跑在真机上差别不大panic 的触发路径是真实的。至于架构选择我建议新手从 x86_64 起步因为编译工具链现成、资料最多。等你熟了再玩 arm64——热词里qemu模拟arm64搜索量很高说明很多人卡在交叉编译这一步。arm64 的坑主要在工具链和-machine virt的设备树第 3 节我会单独说。2.2 内核版本与编译配置的取舍内核版本选哪个我的建议是选一个稳定的长期支持版本比如 6.1 或 6.6 的 LTS。原因很实际太新的版本编译依赖多、配置项变动频繁容易在make menuconfig阶段就劝退太老的版本比如 3.x很多现代调试特性缺失gdb 脚本对不上。热词里有人搜github内核3.10.49怎么root那是嵌入式老平台的玩法和我们要做的通用调试环境不是一回事。编译配置是这套环境里最容易被忽视、也最影响体验的一环。默认的defconfig为了体积精简掉了很多东西调试时会发现符号不全、gdb 看不到变量。所以必须手动打开几个关键选项CONFIG_DEBUG_INFOy生成调试符号这是 gdb 能看源码的前提。CONFIG_DEBUG_INFO_DWARF4yDWARF4 格式兼容性最好gdb 13.2 对它的支持很稳。CONFIG_GDB_SCRIPTSy内核自带一套 gdb 脚本能直接lx-symbols加载符号省去手动add-symbol-file的麻烦。CONFIG_KGDBy和CONFIG_KGDB_SERIAL_CONSOLEy如果你不想用 QEMU 的 gdb stub想走 kgdb 串口调试这两个得开。CONFIG_FRAME_POINTERy让调用栈能完整回溯不然Call Trace里全是问号。CONFIG_MAGIC_SYSRQy配合SysRq键可以手动触发崩溃测试环境必备。这些选项在make menuconfig里分散在不同菜单下找起来烦。我的做法是直接编辑.config文件用scripts/config脚本批量设置比在菜单里翻快得多。2.3 调试器为什么锁定 gdb 13.2gdb 版本不是越新越好也不是随便哪个都行。内核的 gdb 脚本vmlinux-gdb.py对 gdb 的 Python API 有版本要求太老的 gdb比如 8.x跑脚本会报错太新的又可能因为 API 变动导致脚本失效。gdb 13.2 是我实测下来和 6.x 内核配合最顺的版本lx-symbols、lx-dmesg、lx-ps这些命令都能正常用。如果你系统自带的 gdb 版本不对别急着卸载系统包直接从源码编译一个装到/usr/local下用绝对路径调用就行。这样不会破坏系统依赖也不会和apt打架。热词里gdb 13.2被单独搜出来说明确实有人卡在版本匹配上。2.4 整体架构一图说清文字版整套环境的数据流是这样的宿主机上编译出vmlinux带符号的内核镜像和bzImage可引导的压缩镜像QEMU 用bzImage启动客户机同时通过-s打开 gdb stub 监听 1234 端口宿主机上的 gdb 加载vmlinux的符号连上 1234 端口就能对客户机内核下断点、单步、看内存。客户机的串口输出重定向到宿主机的一个文件或终端panic 信息就靠它抓。这个架构里vmlinux和bzImage必须来自同一次编译否则符号地址对不上gdb 断点会飘。这是新手最容易犯的错编译两次忘了同步调半天发现断点根本不停。3. 从零开始的完整搭建实操3.1 宿主机依赖安装与工具链准备先解决依赖。Ubuntu 24.04 上编译内核需要的包比想象中多缺一个都会在编译中途报错。我习惯一次性装齐sudo apt update sudo apt install -y build-essential libncurses-dev bison flex \ libssl-dev libelf-dev bc dwarves zstd git wget \ qemu-system-x86 qemu-system-arm gdb-multiarch这里有几个包值得说明。libncurses-dev是menuconfig的依赖没有它菜单界面出不来dwarves提供pahole工具生成 BTF 信息用现代内核编译会检查zstd是内核镜像压缩格式之一不装的话make会提示找不到压缩工具。qemu-system-x86和qemu-system-arm分别对应两种架构按需装。gdb 这块如果你要用 arm64 调试得装gdb-multiarch因为它支持多架构x86 调试用系统自带的gdb就够。但前面说了版本问题建议单独编译 gdb 13.2wget https://ftp.gnu.org/gnu/gdb/gdb-13.2.tar.xz tar -xf gdb-13.2.tar.xz cd gdb-13.2 ./configure --prefix/usr/local/gdb-13.2 --with-python/usr/bin/python3 make -j$(nproc) sudo make install装完用/usr/local/gdb-13.2/bin/gdb --version验证。这一步编译大概十分钟值得等。3.2 内核源码获取与最小化配置源码从 kernel.org 拉用稳定版wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz tar -xf linux-6.6.tar.xz cd linux-6.6配置阶段我不用defconfig直接开搞而是先make x86_64_defconfig拿到一个基础配置再用scripts/config精准打开调试选项make x86_64_defconfig ./scripts/config --enable DEBUG_INFO ./scripts/config --enable DEBUG_INFO_DWARF4 ./scripts/config --enable GDB_SCRIPTS ./scripts/config --enable FRAME_POINTER ./scripts/config --enable MAGIC_SYSRQ ./scripts/config --enable KGDB ./scripts/config --enable KGDB_SERIAL_CONSOLE ./scripts/config --disable DEBUG_INFO_REDUCED ./scripts/config --disable DEBUG_INFO_SPLIT注意最后两个--disable。DEBUG_INFO_REDUCED会砍掉部分调试信息DEBUG_INFO_SPLIT会把调试信息拆到单独的.dwo文件里gdb 加载时容易找不到。这两个默认可能是开的必须关掉否则 gdb 里看变量全是optimized out。改完执行make olddefconfig让配置生效然后make -j$(nproc)开始编译。第一次编译大概 10 到 20 分钟取决于机器。编译产物里arch/x86/boot/bzImage是启动用的根目录的vmlinux是带符号的调试用镜像两个都要留着。提示编译前确认磁盘空间内核源码加编译产物轻松超过 20GB。df -h看一眼别编到一半空间满了。3.3 根文件系统的最小化制作内核光有镜像还跑不起来得有个根文件系统。最省事的方案是用busybox做一个 initramfs几十兆大小启动快够用。wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2 tar -xf busybox-1.36.1.tar.bz2 cd busybox-1.36.1 make defconfig sed -i s/.*CONFIG_STATIC.*/CONFIG_STATICy/ .config make -j$(nproc) make installCONFIG_STATICy是关键静态链接的 busybox 不依赖外部库initramfs 里不用带一堆.so。装完之后在_install目录下就是完整的根文件系统骨架再手动补几个目录和设备节点cd _install mkdir -p proc sys dev etc/init.d sudo mknod dev/console c 5 1 sudo mknod dev/null c 1 3然后写一个最简单的init脚本挂载 proc 和 sys起一个 shellcat init EOF #!/bin/sh mount -t proc none /proc mount -t sysfs none /sys echo kernel debug env ready exec /bin/sh EOF chmod x init最后打包成 cpiofind . -print0 | cpio --null -ov --formatnewc | gzip -9 ../rootfs.cpio.gz这个rootfs.cpio.gz就是 QEMU 要用的根文件系统。整个过程不到五分钟比折腾发行版镜像快得多。3.4 QEMU 启动参数逐项拆解启动命令是这套环境的核心每个参数都有讲究qemu-system-x86_64 \ -kernel arch/x86/boot/bzImage \ -initrd rootfs.cpio.gz \ -append consolettyS0 nokaslr panic1 \ -nographic \ -s -S \ -m 2G \ -smp 2逐项说。-kernel指定内核镜像-initrd指定根文件系统。-append里的参数传给内核consolettyS0把控制台重定向到串口配合-nographic就能在终端里看到输出nokaslr关闭内核地址空间随机化这是调试的关键——开了 KASLR每次启动内核加载地址都变gdb 断点地址对不上panic1表示 panic 后 1 秒自动重启方便反复测试。-nographic让 QEMU 不弹图形窗口所有输出走终端。-s是-gdb tcp::1234的简写打开 gdb stub-S让 CPU 启动时暂停等 gdb 下continue才跑。这两个配合就能实现内核第一条指令就停下来等你。-m 2G给 2G 内存-smp 2给两个 CPU调试多核场景用得上。如果你要调 arm64命令换成qemu-system-aarch64 \ -machine virt \ -cpu cortex-a57 \ -kernel arch/arm64/boot/Image \ -initrd rootfs.cpio.gz \ -append consolettyAMA0 nokaslr \ -nographic -s -S -m 2G注意 arm64 的控制台是ttyAMA0不是ttyS0镜像路径也不同。-machine virt是 QEMU 的通用虚拟平台设备树由 QEMU 自动生成省去手写 dts 的麻烦。4. gdb 调试内核的实战技巧4.1 连接与符号加载的正确姿势启动 QEMU 后另开一个终端跑 gdb/usr/local/gdb-13.2/bin/gdb vmlinux (gdb) target remote :1234 (gdb) lx-symbols (gdb) continuetarget remote :1234连上 QEMU 的 gdb stub。lx-symbols是内核自带脚本提供的命令它会自动加载内核模块的符号——如果你调的是带模块的场景这一步必不可少。执行完continue客户机内核才开始跑终端里能看到启动日志。这里有个细节lx-symbols依赖vmlinux-gdb.py这个文件在编译产物根目录下。gdb 启动时得能自动加载它通常靠vmlinux同目录的.gdbinit或者手动source vmlinux-gdb.py。如果lx-symbols提示命令不存在八成是脚本没加载手动 source 一下就行。4.2 断点设置与 panic 现场捕获调试内核 panic最常用的手法是在可疑函数上下断点。比如怀疑内存管理有问题就在panic函数本身下断(gdb) break panic (gdb) continue这样一旦内核走到 panicgdb 会立刻停下来此时你能看到完整的调用栈(gdb) bt (gdb) info registers (gdb) frame 3 (gdb) info localsbt看调用栈info registers看寄存器快照frame N切到某一层栈帧info locals看该函数的局部变量。这套组合下来panic 的来龙去脉基本就清楚了。对于已经 panic 但没下断点的情况QEMU 的 gdb stub 依然能连上——panic 后内核虽然死了但 CPU 还在gdb attach 上去还能看现场。这就是 QEMU 相比真机的巨大优势真机 panic 后可能直接重启或者卡死到无法连接QEMU 里现场永远保留。4.3 常用 gdb 命令速查与内核专用扩展内核调试和用户态调试的命令有重叠也有差异我整理了一张常用表命令作用内核调试注意点bt查看调用栈需要FRAME_POINTER才能完整回溯info registers查看寄存器多核时注意当前是哪个 CPUx/10i $pc反汇编当前指令附近确认崩溃指令p variable打印变量优化过的变量可能显示optimized outlx-dmesg查看内核日志缓冲比串口输出更全能看到早期日志lx-ps列出所有进程排查进程相关 panic 很有用lx-lsmod列出已加载模块模块调试必备list显示源码需要源码路径和调试信息匹配lx-dmesg这个命令特别值得说。串口输出有时候会因为缓冲区问题丢日志尤其是 panic 早期的信息。lx-dmesg直接从内核的日志缓冲区里读能拿到最完整的一份。热词里内核缓冲被搜出来说明很多人意识到串口日志不全的问题这个命令就是解法。4.4 用 SysRq 主动触发 panic 做测试环境搭好了怎么验证它真能抓 panic总不能每次都等它自己崩。用 SysRq 主动触发echo c /proc/sysrq-trigger在客户机 shell 里执行这行内核立刻 panic。前提是编译时开了CONFIG_MAGIC_SYSRQy。这个手法在测试调试环境时非常有用——你能精确控制 panic 发生的时机gdb 那边下好断点这边一触发立刻就能验证整条链路通不通。注意/proc/sysrq-trigger需要 root 权限客户机里默认就是 root直接写就行。但别在宿主机上试这行命令那是真的会把宿主机搞崩。5. 踩坑记录与常见问题排查5.1 断点不生效的几种典型原因断点下了不停是新手最常遇到的问题。我总结了几种情况第一种nokaslr没加。KASLR 开着的时候内核每次启动加载地址随机gdb 里vmlinux的符号地址是链接时的固定地址两者对不上断点自然不生效。解决办法就是在-append里加nokaslr。第二种vmlinux和bzImage不是同一次编译的。改了代码只重新make了bzImage没管vmlinux或者反过来符号地址就错位了。养成习惯每次重新编译后两个文件一起更新。第三种断点下在了被内联的函数上。内核大量使用inline你断的函数可能被内联进调用者gdb 找不到独立的函数入口。这时候用break file.c:line按行号下断或者disassemble看实际代码位置。第四种优化级别太高。-O2下很多变量被优化掉断点位置也可能被重排。调试阶段可以在Makefile里临时把-O2改成-O0或者-Og代价是内核跑得慢但调试体验好很多。5.2 串口无输出与启动卡死排查QEMU 启动了但终端一片空白或者卡在某个地方不动排查思路如下。先确认console参数和-nographic匹配。x86 是ttyS0arm64 是ttyAMA0写错了就没输出。然后确认-append里的参数真的传进去了可以在 QEMU 启动时加-d看调试信息或者用-serial mon:stdio把串口和监控台分开。如果卡在Starting kernel ...之后没动静多半是根文件系统的问题。检查rootfs.cpio.gz里的init是不是可执行、/dev/console设备节点在不在。initramfs 的 init 找不到内核会 panic 报No init found这个信息在串口里能看到。还有一种情况是 gdb 那边没continue。因为加了-SCPU 启动就暂停gdb 不执行continue客户机永远不动。这是设计如此不是 bug。5.3 常见问题速查表现象可能原因解决办法gdb 连不上 1234 端口QEMU 没加-s或端口被占检查启动参数ss -tlnp看端口占用lx-symbols命令不存在gdb 脚本没加载手动source vmlinux-gdb.py变量显示optimized out编译优化或调试信息不全关DEBUG_INFO_REDUCED降优化级别panic 后 gdb 看不到栈FRAME_POINTER没开重新编译内核打开该选项客户机启动后无 shellinit 脚本或设备节点缺失检查 initramfs 内容arm64 启动报设备树错误-machine参数不对用-machine virt让 QEMU 自动生成编译报 BTF 相关错误缺pahole工具apt install dwarves5.4 几个提升效率的实操心得第一个心得把 QEMU 启动命令和 gdb 连接命令写成脚本。我习惯在项目根目录放两个脚本run.sh负责启动 QEMUdebug.sh负责起 gdb 并自动连上、加载符号、下好常用断点。每次调试就是./run.sh加./debug.sh省去重复敲命令。第二个心得用tmux分屏。一个 pane 跑 QEMU 看串口输出一个 pane 跑 gdb 下命令切换用快捷键比开两个终端窗口顺手。tmux的Ctrl-b %垂直分屏Ctrl-b 水平分屏用熟了效率翻倍。第三个心得内核日志重定向到文件。QEMU 的-serial file:kernel.log参数能把串口输出直接写文件panic 之后翻日志比在终端里往上滚屏方便得多。配合lx-dmesg一起用日志基本不会丢。第四个心得善用watch命令。gdb 的watch variable能在变量被修改时停下来排查内存被意外改写的问题特别有效。内核里调内存越界这个命令能帮你精确定位到哪一行代码改坏了数据。6. 环境搭好之后能做什么这套环境跑通之后你能做的事情比想象中多。最直接的是复现各种 panic故意写一个空指针解引用、故意在中断上下文里睡眠、故意制造内存越界看内核怎么报错、调用栈长什么样。这种主动制造错误的练习比被动等 bug 出现高效得多。再进一步可以拿它来读内核源码。比如你想搞懂kmalloc到底怎么分配内存就在__kmalloc上下个断点跑一个触发分配的程序单步跟进去看每一层调用。源码配合运行时行为理解速度比干啃代码快十倍。热词里linux的内核详解被频繁搜索说明很多人想深入理解内核但光看书不够得有个能动手的环境。还能做内核模块开发。写一个简单的hello world模块编译成.ko在客户机里insmod用lx-lsmod看模块加载情况在模块函数上下断点调试。模块调试和内核本体调试流程一样但模块可以随时加载卸载迭代更快。最后这套环境是学习内核虚拟化的基础。热词里linux内核虚拟化、qemu kvm开发都指向这个方向。QEMU 本身就是虚拟化工具你在它上面跑内核、调内核对虚拟化的理解会自然加深。等你想研究 KVM 的时候这套调试环境直接就能复用。我个人在实际操作中的体会是内核调试最大的门槛不是技术难度而是环境搭建的繁琐。很多人卡在编译报错、启动失败、gdb 连不上这些脏活上还没摸到内核的门就放弃了。把这套环境一次性搭好、脚本化、文档化后面每次调试都是几分钟的事学习曲线一下子就平缓了。这套东西我用了好几年从 x86 到 arm64从 4.x 内核到 6.x 内核骨架一直没变只是参数微调。你把它跑通一次以后遇到任何内核问题都有了一个可以随时开工的案发现场。