目錄
【PART 1 Kernel 除錯的簡介與方法】
chapter 1 軟體除錯概論
1.1 技術需求
1.2 軟體除錯 – 定義、起源與由來
1.3 軟體錯誤：真實案例
1.4 設定工作區
1.5 兩個 kernel 的故事
1.6 幾個簡單的 Debug 技巧提示
結論
chapter 2 Debug Kernel 的方法
2.1 技術需求
2.2 分類 bug type
2.3 Debug Kernel：方法不同的原因
2.4 概述 debug kernel 的不同方法
結論
【PART 2 Kernel 與驅動程式的除錯工具與技術】
chapter 3 透過檢測除錯：使用 printk 與其族類
3.1 技術需求
3.2 無所不在的 kernel printk
3.3 將 printk 用於除錯目的
3.4 使用 kernel 強大的動態 debug 功能
3.5 剩下的 printk 雜項字元
結論
chapter 4 透過Kprobes 儀器進行debug
4.1 了解 kprobes 基礎
4.2 使用 static kprobes – 傳統的探測方法
4.3 了解 ABI 的基本概念
4.4 使用 static kprobes – 範例 3 與範例 4
4.5 開始使用 kretprobes
4.6 Kprobes：限制性與不利因素
4.7 更簡單的方法：動態 kprobes 或基於 kprobes 的事件追蹤
4.8 透過 perf 和 eBPF 工具，對 execve() API 進行 trap
結論
chapter 5 Kernel 記憶體除錯問題初探
5.1 技術需求
5.2 記憶體到底出了什麼問題？
5.3 使用 KASAN 和 UBSAN 找到記憶體 bug
5.4 使用 Clang 編譯 kernel 和 module
5.5 捕捉 kernel 中的記憶體缺陷：比較與注意事項 (Part 1)
結論
chapter 6 再論 Kernel 記憶體除錯問題
6.1 技術需求
6.2 透過 SLUB debug 偵測 slab 記憶體損毀
6.3 使用 kmemleak 找出記憶體洩漏問題
6.4 捕捉 kernel 中的記憶體缺陷：比較與注意事項(Part 2)
結論
chapter 7 Oops！解讀 kernel 的 bug 診斷
7.1 技術需求
7.2 產生一個簡單的 kernel bug 和 Oops
7.3 介紹 Kernel Oops 以及所代表的意義
7.4 魔鬼藏在細節裡：解碼 Oops
7.5 協助判斷 Oops 位置的工具與技術
7.6 ARM Linux 系統上的 Oops 及使用 Netconsole
7.7 幾個實際的 Oops
結論
chapter 8 鎖的除錯
8.1 技術需求
8.2 上鎖與 debug 因鎖產生的 bug
8.3 上鎖：快速總結要點
8.4 使用 KCSAN 攔截 concurrency bug
8.5 一些實際案例：由於上鎖問題導致的 kernel bug
結論
【PART 3 額外的 Kernel 除錯工具與技術】
chapter 9 追蹤 Kernel 流程
9.1 技術需求
9.2 Kernel 追蹤技術：概論
9.3 使用 ftrace kernel 追蹤程式
9.4 使用 trace-cmd、KernelShark 與 perf-tools ftrace 前端工具
9.5 用 LTTng 和 Trace Compass 追蹤 kernel 的簡介
結論
chapter 10 Kernel Panic、Lockup 以及 Hang
10.1 技術需求
10.2 Panic！Kernel panic 時會發生什麼事？
10.3 撰寫自訂的 kernel panic 處理常式
10.4 偵測 kernel 中的 lockup 和 CPU 停止
10.5 採用 kernel 的掛起任務和工作佇列停止偵測器
結論
chapter 11 使用 Kernel GDB (KGDB)
11.1 技術需求
11.2 從概念上理解 KGDB 的運作
11.3 為 KGDB 建立 ARM target 系統和 kernel
11.4 使用 KGDB debug kernel
11.5 使用 KGDB debug kernel 模組
11.6 [K]GDB：一些提示和技巧
結論
chapter 12 再談談一些 kernel debug 方法
12.1 Kdump/crash 架構簡介
12.2 淺談 kernel 程式碼的靜態分析
12.3 Kernel code coverage 工具和測試框架簡介
12.4 其他：使用 journalctl、斷言 (assertions) 和警告
結論
索引
