答案是dmesg和符号解析为内核模块调试核心。系统崩溃时，dmesg输出Oops等错误及PC寄存器地址；结合带-g调试信息编译的.ko文件与addr2line或gdb工具，可将地址还原为源码行号，定位问题。
当Linux内核模块发生崩溃时，系统通常不会像用户程序那样给出明确的错误提示。调试这类问题的关键在于理解内核日志输出和符号解析机制。dmesg是获取内核打印信息的核心工具，而符号表则是将内存地址还原为函数名、变量名的基础。掌握这两者结合使用的方法，能有效定位模块崩溃原因。
dmesg查看内核崩溃信息
内核模块出错后，第一条线索往往来自dmesg输出。系统在发生Oops或panic时会自动打印寄存器状态、调用栈和出错地址。
运行以下命令查看最近的内核消息：
dmesg | tail -20重点关注包含“Oops”、“BUG”、“WARNING:”或“Unable to handle kernel paging request”的行。例如：
[ 1234.567890] Unable to handle kernel paging request at virtual address ffffff00 [ 1234.567891] pgd = c0004000 [ 1234.567892] *pgd=00000000 [ 1234.567893] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 1234.567894] Modules linked in: mymodule(+) [ 1234.567895] CPU: 0 PID: 123 Comm: insmod Not tainted 5.15.0-rc1+ #1 [ 1234.567896] Hardware name: Generic DT based system [ 1234.567897] PC is at mymodule_do_something+0x24/0x100 [mymodule] [ 1234.567898] LR is at init_module+0x18/0x1000 [mymodule]这里的PC（程序计数器）指向了崩溃位置：mymodule_do_something+0x24，说明问题出现在该函数偏移0x24字节处。
确保模块编译包含调试符号
要将地址转换为源码级别的函数名，必须保证模块编译时启用了调试信息。Makefile中应包含以下选项：
- GCC编译参数加入 -g 以生成调试信息
- 避免 strip 模块文件
- 保留 .ko 文件与运行环境一致
典型的模块Makefile示例：
obj-m += mymodule.o CFLAGS_mymodule.o := -g -O2 KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) M=$(PWD) modules编译完成后，.ko文件中会包含足够的ELF调试信息，供后续分析使用。
使用addr2line或gdb解析崩溃地址
有了带符号的.ko文件和崩溃地址，就可以进行反向定位。假设Oops中显示PC位于 mymodule_do_something+0x24，先提取函数起始地址。
通过readelf获取函数虚拟地址：
readelf -s mymodule.ko | grep mymodule_do_something输出可能为：
55: c0000120 64 FUNC GLOBAL DEFAULT 1 mymodule_do_something
函数起始地址为c0000120，偏移0x24对应的实际地址是 c0000120 + 0x24 = c0000144。
使用addr2line查找源码位置：
addr2line -e mymodule.ko 0xc0000144输出类似：
/home/dev/mymodule/main.c:45这表示崩溃发生在main.c第45行。也可以用gdb加载模块进行更深入分析：
gdb mymodule.ko (gdb) list *mymodule_do_something+0x24处理未导出符号或内核自身崩溃
如果崩溃涉及内核函数而非模块本身，需使用vmlinux镜像配合分析。vmlinux是带符号的内核镜像，通常位于/boot或内核源码目录下。
使用相同方法解析内核地址：
addr2line -e /usr/src/linux/vmlinux 0xc0123456注意：某些发行版提供分开的debuginfo包（如kernel-debuginfo），需单独安装才能获得vmlinux。
另外，可借助scripts/decode_stacktrace.sh脚本（存在于内核源码中）自动完成符号翻译：
dmesg | tail -20 > oops.txt ./scripts/decode_stacktrace.sh oops.txt vmlinux基本上就这些。关键点在于保留完整的调试符号、准确匹配运行中的模块版本，并熟练使用dmesg与地址解析工具组合排查问题。虽然过程看似繁琐，但一旦掌握，内核模块调试效率会显著提升。
