扫码关注
本文概述
内核调试是嵌入式Linux工程师的核心技能，也是面试的加分点。面试官想听的不是“printk打点”，而是你懂不懂不同调试手段的适用场景：printk看流程、ftrace看函数调用和调度、kgdb/kdump做交互和crash分析、perf做性能。本文从“先定位问题类型再选手段”讲起，讲printk的级别和开关、ftrace的function_graph与trace事件、kgdb断点调试、kdump/crash分析、以及串口console和日志抓取的实战要点，强调手段选择依赖问题现象（崩溃/死锁/性能/逻辑错误），不套固定流程。
核心要点
调试先分类问题：崩溃、死锁、逻辑错误、性能问题，再选手段
printk：打点看流程和值，注意级别（KERN_ERR等）、动态开关和刷盘时机
ftrace：function_graph看调用链、trace事件看调度和中断，适合定位死锁和调用顺序
kgdb：内核断点调试，适合单步跟踪复杂逻辑，需要串口连接
kdump+c crash：内核崩溃现场分析，适合难以复现的oops/panic
perf：性能问题（CPU、锁竞争、延迟）分析，和ftrace配合
面试官考察点
考察点拆解
面试官问内核调试，重点考察：第一，你懂不懂按问题类型选调试手段，而不是只会printk；第二，你懂不懂printk的用法细节（级别、console、dmesg）；第三，你懂不懂ftrace的能力（函数跟踪、事件跟踪）；第四，你有没有真正定位过内核问题的实战经验，能讲清思路。
追问方向：printk级别、dmesg和console区别、ftrace怎么开、kgdb怎么连、oops怎么分析、死锁怎么定位。
回答思路
答题主线
建议按“问题分类 → 手段矩阵 → 两个实战例子 → 工具配合”来答，体现你调过真问题。
先讲思路：先判断问题类型。
讲手段：printk、ftrace、kgdb、kdump、perf各适用什么。
讲实战：举一个你定位过的具体问题的例子。
讲配合：多手段组合用。
参考回答
我先讲调试的思路，再讲各个手段怎么选。
第一，先分类问题。内核问题先判断类型：是崩溃（oops/panic）、死锁/卡死、逻辑错误（行为不对但不崩）、还是性能问题（慢、延迟高）。不同类型用不同手段，用错工具效率很低。
第二，手段矩阵。
printk：最基础的打点手段，看流程走到哪、变量值是什么。注意：用合适的级别（KERN_ERR等）、生产环境用动态开关（dynamic_debug）控制打印、记得printk是异步刷console的，崩溃前的打印可能没刷出来；
ftrace：内核级跟踪。function_graph能看完整函数调用链（谁调了谁、在哪耗时），trace事件能看调度、中断、irq等事件序列，适合定位死锁（看锁等待顺序）、调用顺序异常和部分性能问题；
kgdb：内核断点调试，像应用gdb一样打断点、单步、看变量，需要目标机串口连接主机。适合复杂逻辑错误，但会暂停系统，不能用于时序敏感场景；
kdump + crash：系统崩溃（panic/oops）时把内存转储保存，重启后用crash工具分析崩溃现场（调用栈、寄存器、内存），适合难以复现或线上崩溃；
perf：性能分析，看CPU热点、锁竞争、调度延迟，性能问题用它。
第三，实战思路举例。比如怀疑驱动死锁：先用ftrace的lockdep和function_graph看锁获取顺序和调用链，确认死锁的两个持锁路径；再配合printk打点确认执行顺序。比如oops：看crash dump的调用栈（Oops message里的PC、LR、堆栈回溯），定位到具体函数和行，再对照源码分析。
第四，工具配合。实际调试经常组合：printk看流程 → ftrace看调用链 → kgdb单步确认 → kdump留存现场。能远程抓日志（串口console、网络console）很重要，很多问题只在长时间运行后出现。
