本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可, 轉載請註明出處, 謝謝合作
因本人技術水平和知識面有限, 內容如有紕漏或者需要修正的地方, 歡迎大家指正, 也歡迎大家提供一些其他好的除錯工具以供收錄, 鄙人在此謝謝啦

"除錯難度本來就是寫程式碼的兩倍. 因此, 如果你寫程式碼的時候聰明用盡, 根據定義, 你就沒有能耐去除錯它了."
        --Brian Kernighan

1 核心除錯以及工具總結

核心總是那麼捉摸不透, 核心也會犯錯, 但是除錯卻不能像使用者空間程式那樣, 為此核心開發者為我們提供了一系列的工具和系統來支援核心的除錯.

核心的除錯, 其本質是核心空間與使用者空間的資料交換, 核心開發者們提供了多樣的形式來完成這一功能.

工具	描述
debugfs等檔案系統	提供了 procfs, sysfs, debugfs以及 relayfs 來與使用者空間進行資料互動, 尤其是 debugfs, 這是核心開發者們實現的專門用來除錯的檔案系統介面. 其他的工具或者介面, 多數都依賴於 debugfs.
printk	強大的輸出系統, 沒有什麼邏輯上的bug是用PRINT解決不了的
ftrace以及其前端工具trace-cmd等	核心提供了 ftrace 工具來實現檢查點, 事件等的檢測, 這一框架依賴於 debugfs , 他在 debugfs 中的 tracing 子系統中為使用者提供了豐富的操作介面, 我們可以通過該系統對核心實現檢測和分析. 功能雖然強大, 但是其操作並不是很簡單, 因此使用者們為實現了 trace-cmd 等前端工具, 簡化了 ftrace 的使用.
kprobe以及更強大的systemtap	核心中實現的 krpobe 通過類似與程式碼劫持一樣的技巧, 在核心的程式碼或者函式執行前後, 強制加上某些除錯資訊, 可以很巧妙的完成除錯工作, 這是一項先進的除錯技術, 但是仍然有覺得它不夠好, 劫持程式碼需要用驅動的方式編譯並載入, 能不能通過指令碼的方式自動生成劫持程式碼並自動載入和收集資料, 於是systemtap 出現了. 通過 systemtap 使用者只需要編寫指令碼, 就可以完成除錯並動態分析核心
kgdb && kgtp	KGDB 是大名鼎鼎的核心除錯工具, KGTP則通過驅動的方式強化了 gdb的功能, 諸如tracepoint, 列印核心變數等.
perf	erf Event是一款隨 inux核心程式碼一同釋出和維護的效能診斷工具, 核社群維護和發展. Perf 不僅可以用於應用程式的效能統計分析, 也可以應用於核心程式碼的效能統計和分析. 得益於其優秀的體系結構設計, 越來越多的新功能被加入 Perf, 使其已經成為一個多功能的效能統計工具集
LTTng	LTTng 是一個 Linux 平臺開源的跟蹤工具, 是一套軟體元件, 可允許跟蹤 Linux 核心和使用者程式, 並控制跟蹤會話(開始/停止跟蹤、啟動/停止事件 等等).

2 使用者空間與核心空間資料交換的檔案系統

核心中有三個常用的偽檔案系統: procfs, debugfs和sysfs.

檔案系統	描述
procfs	The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures.
sysfs	The filesystem for exporting kernel objects.
debugfs	Debugfs exists as a simple way for kernel developers to make information available to user space.
relayfs	A significantly streamlined version of relayfs was recently accepted into the -mm kernel tree.

它們都用於Linux核心和使用者空間的資料交換, 但是適用的場景有所差異：

• procfs 歷史最早, 最初就是用來跟核心互動的唯一方式, 用來獲取處理器、記憶體、裝置驅動、程序等各種資訊.

• sysfs 跟 kobject 框架緊密聯絡, 而 kobject 是為裝置驅動模型而存在的, 所以 sysfs 是為裝置驅動服務的.

• debugfs 從名字來看就是為 debug 而生, 所以更加靈活.

• relayfs 是一個快速的轉發 (relay) 資料的檔案系統, 它以其功能而得名. 它為那些需要從核心空間轉發大量資料到使用者空間的工具和應用提供了快速有效的轉發機制.

2.1 procfs檔案系統

• ProcFs 介紹`

procfs 是比較老的一種使用者態與核心態的資料交換方式, 核心的很多資料都是通過這種方式出口給使用者的, 核心的很多引數也是通過這種方式來讓使用者方便設定的. 除了 sysctl 出口到 /proc 下的引數, procfs 提供的大部分核心引數是隻讀的. 實際上, 很多應用嚴重地依賴於procfs, 因此它幾乎是必不可少的元件. 前面部分的幾個例子實際上已經使用它來出口核心資料, 但是並沒有講解如何使用, 本節將講解如何使用procfs.

• 參考資料

2.2 sysfs檔案系統

核心子系統或裝置驅動可以直接編譯到核心, 也可以編譯成模組, 編譯到核心, 使用前一節介紹的方法通過核心啟動引數來向它們傳遞引數, 如果編譯成模組, 則可以通過命令列在插入模組時傳遞引數, 或者在執行時, 通過 sysfs 來設定或讀取模組資料.

Sysfs 是一個基於記憶體的檔案系統, 實際上它基於ramfs, sysfs 提供了一種把核心資料結構, 它們的屬性以及屬性與資料結構的聯絡開放給使用者態的方式, 它與 kobject 子系統緊密地結合在一起, 因此核心開發者不需要直接使用它, 而是核心的各個子系統使用它. 使用者要想使用 sysfs 讀取和設定核心引數, 僅需裝載 sysfs 就可以通過檔案操作應用來讀取和設定核心通過 sysfs 開放給使用者的各個引數：

mkdir -p /sysfs
mount -t sysfs sysfs /sysfs

注意, 不要把 sysfs 和 sysctl 混淆, sysctl 是核心的一些控制引數, 其目的是方便使用者對核心的行為進行控制, 而 sysfs 僅僅是把核心的 kobject 物件的層次關係與屬性開放給使用者檢視, 因此 sysfs 的絕大部分是隻讀的, 模組作為一個 kobject 也被出口到 sysfs, 模組引數則是作為模組屬性出口的, 核心實現者為模組的使用提供了更靈活的方式, 允許使用者設定模組引數在 sysfs 的可見性並允許使用者在編寫模組時設定這些引數在 sysfs 下的訪問許可權, 然後使用者就可以通過 sysfs 來檢視和設定模組引數, 從而使得使用者能在模組執行時控制模組行為.

2.3 debugfs檔案系統

核心開發者經常需要向用戶空間應用輸出一些除錯資訊, 在穩定的系統中可能根本不需要這些除錯資訊, 但是在開發過程中, 為了搞清楚核心的行為, 除錯資訊非常必要, printk可能是用的最多的, 但它並不是最好的, 除錯資訊只是在開發中用於除錯, 而 printk 將一直輸出, 因此開發完畢後需要清除不必要的 printk 語句, 另外如果開發者希望使用者空間應用能夠改變核心行為時, printk 就無法實現.

因此, 需要一種新的機制, 那只有在需要的時候使用, 它在需要時通過在一個虛擬檔案系統中建立一個或多個檔案來向用戶空間應用提供除錯資訊.

有幾種方式可以實現上述要求：

• 使用 procfs, 在 /proc 建立檔案輸出除錯資訊, 但是 procfs 對於大於一個記憶體頁(對於 x86 是 4K)的輸出比較麻煩, 而且速度慢, 有時回出現一些意想不到的問題.

• 使用 sysfs( 2.6 核心引入的新的虛擬檔案系統), 在很多情況下, 除錯資訊可以存放在那裡, 但是sysfs主要用於系統管理，它希望每一個檔案對應核心的一個變數，如果使用它輸出複雜的資料結構或除錯資訊是非常困難的.

• 使用 libfs 建立一個新的檔案系統, 該方法極其靈活, 開發者可以為新檔案系統設定一些規則, 使用 libfs 使得建立新檔案系統更加簡單, 但是仍然超出了一個開發者的想象.

為了使得開發者更加容易使用這樣的機制, Greg Kroah-Hartman 開發了 debugfs(在 2.6.11 中第一次引入), 它是一個虛擬檔案系統, 專門用於輸出除錯資訊, 該檔案系統非常小, 很容易使用, 可以在配置核心時選擇是否構件到核心中, 在不選擇它的情況下, 使用它提供的API的核心部分不需要做任何改動.

2.4 relayfs檔案系統

relayfs 是一個快速的轉發(relay)資料的檔案系統, 它以其功能而得名. 它為那些需要從核心空間轉發大量資料到使用者空間的工具和應用提供了快速有效的轉發機制.

Channel 是 relayfs 檔案系統定義的一個主要概念, 每一個 channel 由一組核心快取組成, 每一個 CPU 有一個對應於該 channel 的核心快取, 每一個核心快取用一個在 relayfs 檔案系統中的檔案檔案表示, 核心使用 relayfs 提供的寫函式把需要轉發給使用者空間的資料快速地寫入當前 CPU 上的 channel 核心快取, 使用者空間應用通過標準的檔案 I/ O函式在對應的 channel 檔案中可以快速地取得這些被轉發出的資料 mmap 來. 寫入到 channel 中的資料的格式完全取決於核心中建立channel 的模組或子系統.

relayfs 的使用者空間API :

relayfs 實現了四個標準的檔案 I/O 函式, open、mmap、poll和close

函式	描述
open	開啟一個 channel 在某一個 CPU 上的快取對應的檔案.
mmap	把開啟的 channel 快取對映到呼叫者程序的記憶體空間.
read	讀取 channel 快取, 隨後的讀操作將看不到被該函式消耗的位元組, 如果 channel 的操作模式為非覆蓋寫, 那麼使用者空間應用在有核心模組寫時仍可以讀取, 但是如 channel 的操作模式為覆蓋式, 那麼在讀操作期間如果有核心模組進行寫，結果將無法預知, 因此對於覆蓋式寫的 channel, 使用者應當在確認在 channel 的寫完全結束後再進行讀.
poll	用於通知使用者空間應用轉發資料跨越了子快取的邊界, 支援的輪詢標誌有 POLLIN、POLLRDNORM 和 POLLERR
close	關閉 open 函式返回的檔案描述符, 如果沒有程序或核心模組開啟該 channel 快取, close 函式將釋放該channel 快取

注意 : 使用者態應用在使用上述 API 時必須保證已經掛載了 relayfs 檔案系統, 但核心在建立和使用 channel時不需要relayfs 已經掛載. 下面命令將把 relayfs 檔案系統掛載到 /mnt/relay.

2.5 seq_file

一般地, 核心通過在 procfs 檔案系統下建立檔案來向用戶空間提供輸出資訊, 使用者空間可以通過任何文字閱讀應用檢視該檔案資訊, 但是 procfs 有一個缺陷, 如果輸出內容大於1個記憶體頁, 需要多次讀, 因此處理起來很難, 另外, 如果輸出太大, 速度比較慢, 有時會出現一些意想不到的情況, Alexander Viro 實現了一套新的功能, 使得核心輸出大檔案資訊更容易, 該功能出現在 2.4.15(包括 2.4.15)以後的所有 2.4 核心以及 2.6 核心中, 尤其是在 2.6 核心中，已經大量地使用了該功能

3 printk

在核心除錯技術之中, 最簡單的就是 printk 的使用了, 它的用法和C語言應用程式中的 printf 使用類似, 在應用程式中依靠的是 stdio.h 中的庫, 而在 linux 核心中沒有這個庫, 所以在 linux 核心中, 實現了自己的一套庫函式, printk 就是標準的輸出函式

4 ftrace && trace-cmd

4.1 trace && ftrace

Linux當前版本中, 功能最強大的除錯、跟蹤手段. 其最基本的功能是提供了動態和靜態探測點, 用於探測核心中指定位置上的相關資訊.

靜態探測點, 是在核心程式碼中呼叫 ftrace 提供的相應介面實現, 稱之為靜態是因為, 是在核心程式碼中寫死的, 靜態編譯到核心程式碼中的, 在核心編譯後, 就不能再動態修改. 在開啟 ftrace 相關的核心配置選項後, 核心中已經在一些關鍵的地方設定了靜態探測點, 需要使用時, 即可檢視到相應的資訊.

動態探測點, 基本原理為 : 利用 mcount 機制, 在核心編譯時, 在每個函式入口保留數個位元組, 然後在使用 ftrace時, 將保留的位元組替換為需要的指令, 比如跳轉到需要的執行探測操作的程式碼。

ftrace 的作用是幫助開發人員瞭解 Linux 核心的執行時行為, 以便進行故障除錯或效能分析.

最早 ftrace 是一個 function tracer, 僅能夠記錄核心的函式呼叫流程. 如今 ftrace 已經成為一個 framework, 採用 plugin 的方式支援開發人員新增更多種類的 trace 功能.

Ftrace 由 RedHat 的 Steve Rostedt 負責維護. 到 2.6.30 為止, 已經支援的 tracer 包括 :

Tracer	描述
Function tracer 和 Function graph tracer	跟蹤函式呼叫
Schedule switch tracer	跟蹤程序排程情況
Wakeup tracer	跟蹤程序的排程延遲, 即高優先順序程序從進入 ready 狀態到獲得 CPU 的延遲時間. 該 tracer 只針對實時程序
Irqsoff tracer	當中斷被禁止時, 系統無法相應外部事件, 比如鍵盤和滑鼠, 時鐘也無法產生 tick 中斷. 這意味著系統響應延遲, irqsoff 這個 tracer 能夠跟蹤並記錄核心中哪些函式禁止了中斷, 對於其中中斷禁止時間最長的, irqsoff 將在 log 檔案的第一行標示出來, 從而使開發人員可以迅速定位造成響應延遲的罪魁禍首.
Preemptoff tracer	和前一個 tracer 類似, preemptoff tracer 跟蹤並記錄禁止核心搶佔的函式, 並清晰地顯示出禁止搶佔時間最長的核心函式.
Preemptirqsoff tracer	同上, 跟蹤和記錄禁止中斷或者禁止搶佔的核心函式, 以及禁止時間最長的函式.
Branch tracer	跟蹤核心程式中的 likely/unlikely 分支預測命中率情況. Branch tracer 能夠記錄這些分支語句有多少次預測成功. 從而為優化程式提供線索.
Hardware branch tracer	利用處理器的分支跟蹤能力, 實現硬體級別的指令跳轉記錄. 在 x86 上, 主要利用了 BTS 這個特性.
Initcall tracer	記錄系統在 boot 階段所呼叫的 init call.
Mmiotrace tracer	記錄 memory map IO 的相關資訊.
Power tracer	記錄系統電源管理相關的資訊
Sysprof tracer	預設情況下, sysprof tracer 每隔 1 msec 對核心進行一次取樣，記錄函式呼叫和堆疊資訊.
Kernel memory tracer	記憶體 tracer 主要用來跟蹤 slab allocator 的分配情況. 包括 kfree, kmem_cache_alloc 等 API 的呼叫情況, 使用者程式可以根據 tracer 收集到的資訊分析內部碎片情況, 找出記憶體分配最頻繁的程式碼片斷, 等等.
Workqueue statistical tracer	這是一個 statistic tracer, 統計系統中所有的 workqueue 的工作情況, 比如有多少個 work 被插入 workqueue, 多少個已經被執行等. 開發人員可以以此來決定具體的 workqueue 實現, 比如是使用 single threaded workqueue 還是 per cpu workqueue.
Event tracer	跟蹤系統事件, 比如 timer, 系統呼叫, 中斷等.

這裡還沒有列出所有的 tracer, ftrace 是目前非常活躍的開發領域, 新的 tracer 將不斷被加入核心。

4.2 ftrace前端工具trace-cmd

• trace-cmd 介紹

trace-cmd 和 開源的 kernelshark 均是核心Ftrace 的前段工具, 用於分分析核效能.

他們相當於是一個 /sys/kernel/debug/tracing 中檔案系統介面的封裝, 為使用者提供了更加直接和方便的操作.

• 使用

#  收集資訊
sudo trace-cmd reord subsystem:tracing 

#  解析結果
#sudo trace-cmd report

其本質就是對/sys/kernel/debug/tracing/events 下各個模組進行操作, 收集資料並解析

5 Kprobe && systemtap

5.1 核心kprobe機制

kprobe 是 linux 核心的一個重要特性, 是一個輕量級的核心除錯工具, 同時它又是其他一些更高階的核心除錯工具(比如 perf 和 systemtap)的 “基礎設施”, 4.0版本的核心中, 強大的 eBPF 特性也寄生於 kprobe 之上, 所以 kprobe 在核心中的地位就可見一斑了.

Kprobes 提供了一個強行進入任何核心例程並從中斷處理器無干擾地收集資訊的介面. 使用 Kprobes 可以收集處理器暫存器和全域性資料結構等除錯資訊。開發者甚至可以使用 Kprobes 來修改 暫存器值和全域性資料結構的值.

如何高效地除錯核心?

printk 是一種方法, 但是 printk 終歸是毫無選擇地全量輸出, 某些場景下不實用, 於是你可以試一下tracepoint, 我使能 tracepoint 機制的時候才輸出. 對於傻傻地放置 printk 來輸出資訊的方式, tracepoint 是個進步, 但是 tracepoint 只是核心在某些特定行為(比如程序切換)上部署的一些靜態錨點, 這些錨點並不一定是你需要的, 所以你仍然需要自己部署tracepoint, 重新編譯核心. 那麼 kprobe 的出現就很有必要了, 它可以在執行的核心中動態插入探測點, 執行你預定義的操作.

它的基本工作機制是 : 使用者指定一個探測點, 並把一個使用者定義的處理函式關聯到該探測點, 當核心執行到該探測點時, 相應的關聯函式被執行，然後繼續執行正常的程式碼路徑.

kprobe 實現了三種類型的探測點 : kprobes, jprobes和 kretprobes(也叫返回探測點). kprobes 是可以被插入到核心的任何指令位置的探測點, jprobes 則只能被插入到一個核心函式的入口, 而 kretprobes 則是在指定的核心函式返回時才被執行.

5.2 前端工具systemtap

SystemTap 是監控和跟蹤執行中的 Linux 核心的操作的動態方法. 這句話的關鍵詞是動態, 因為 SystemTap 沒有使用工具構建一個特殊的核心, 而是允許您在執行時動態地安裝該工具. 它通過一個 Kprobes 的應用程式設計介面 (API) 來實現該目的.

SystemTap 與一種名為 DTrace 的老技術相似，該技術源於 Sun Solaris 作業系統. 在 DTrace 中, 開發人員可以用 D 程式語言(C 語言的子集, 但修改為支援跟蹤行為)編寫指令碼. DTrace 指令碼包含許多探針和相關聯的操作, 這些操作在探針 “觸發” 時發生. 例如, 探針可以表示簡單的系統呼叫，也可以表示更加複雜的互動，比如執行特定的程式碼行

DTrace 是 Solaris 最引人注目的部分, 所以在其他作業系統中開發它並不奇怪. DTrace 是在 Common Development and Distribution License (CDDL) 之下發行的, 並且被移植到 FreeBSD 作業系統中.

另一個非常有用的核心跟蹤工具是 ProbeVue, 它是 IBM 為 IBM® AIX® 作業系統 6.1 開發的. 您可以使用 ProbeVue 探查系統的行為和效能, 以及提供特定程序的詳細資訊. 這個工具使用一個標準的核心以動態的方式進行跟蹤.

考慮到 DTrace 和 ProbeVue 在各自的作業系統中的巨大作用, 為 Linux 作業系統策劃一個實現該功能的開源專案是勢不可擋的. SystemTap 從 2005 年開始開發, 它提供與 DTrace 和 ProbeVue 類似的功能. 許多社群還進一步完善了它, 包括 Red Hat、Intel、Hitachi 和 IBM 等.

這些解決方案在功能上都是類似的, 在觸發探針時使用探針和相關聯的操作指令碼.

6 kgdb && kgtp

6.1 kgdb

• KDB 和 KGDB 合併, 並進入核心

KGDB 是大名鼎鼎的核心除錯工具, 他是由 KDB 和 KGDB 專案合併而來.

kdb 是一個Linux系統的核心偵錯程式, 它是由SGI公司開發的遵循GPL許可證的開放原始碼除錯工具. kdb 嵌入在Linux 核心中. 為核心&&驅動程式設計師提供除錯手段. 它適合於除錯核心空間的程式程式碼. 譬如進行裝置驅動程式除錯. 核心模組的除錯等.

kgdb 和 kdb 現在已經合併了. 對於一個正在執行的kgdb 而言, 可以使用 gdbmonitor 命令來使用 kdb 命令. 比如

(gdb)gdb monitor ps -A

就可以執行 kdb 的 ps 命令了.

分析一下 kdb 補丁和合入主線的 kdb 有啥不同

kdb跟 kgdb 合併之後, 也可以使用 kgdb 的IO 驅動(比如鍵盤), 但是同時也 kdb也喪失了一些功能. 合併之後的kdb不在支援彙編級的原始碼除錯. 因此它現在也是平臺獨立的.

1. kdump和kexec已經被移除。

2. 從/proc/meninfo中獲取的資訊比以前少了。

3. bt命令現在使用的是核心的backtracer，而不是kdb原來使用的反彙編。

4. 合併之後的kdb不在具有原來的反彙編（id命令）

總結一下 : kdb 和 kgdb 合併之後，系統中對這兩種除錯方式幾乎沒有了明顯的界限，比如通過串列埠進行遠端訪問的時候，可以使用 kgdb 命令, 也可以使用 kdb 命令（使用gdb monitor實現）

6.2 KGTP

KGTP 是一個 實時 輕量級 Linux 偵錯程式 和 跟蹤器. 使用 KGTP

使用 KGTP 不需要在 Linux 核心上打 PATCH 或者重新編譯, 只要編譯KGTP模組並 insmod 就可以.

其讓 Linux 核心提供一個遠端 GDB 除錯介面, 於是在本地或者遠端的主機上的GDB可以在不需要停止核心的情況下用 GDB tracepoint 和其他一些功能 除錯 和 跟蹤 Linux.

KGTP支援 X86-32 ， X86-64 ， MIPS 和 ARM 。
KGTP在Linux核心 2.6.18到upstream 上都被測試過。
而且還可以用在 Android 上(見 HowToUseKGTPinAndroid)

7 perf

Perf 是用來進行軟體效能分析的工具。
通過它, 應用程式可以利用 PMU, tracepoint 和核心中的特殊計數器來進行效能統計. 它不但可以分析指定應用程式的效能問題 (per thread). 也可以用來分析核心的效能問題, 當然也可以同時分析應用程式碼和核心，從而全面理解應用程式中的效能瓶頸.

最初的時候, 它叫做 Performance counter, 在 2.6.31 中第一次亮相. 此後他成為核心開發最為活躍的一個領域. 在 2.6.32 中它正式改名為 Performance Event, 因為 perf 已不再僅僅作為 PMU 的抽象, 而是能夠處理所有的效能相關的事件.

使用 perf, 您可以分析程式執行期間發生的硬體事件，比如 instructions retired , processor clock cycles 等; 您也可以分析軟體事件, 比如 Page Fault 和程序切換。
這使得 Perf 擁有了眾多的效能分析能力, 舉例來說，使用 Perf 可以計算每個時鐘週期內的指令數, 稱為 IPC, IPC 偏低表明程式碼沒有很好地利用 CPU.

Perf 還可以對程式進行函式級別的取樣, 從而瞭解程式的效能瓶頸究竟在哪裡等等. Perf 還可以替代 strace, 可以新增動態核心 probe 點. 還可以做 benchmark 衡量排程器的好壞.

人們或許會稱它為進行效能分析的”瑞士軍刀”, 但我不喜歡這個比喻, 我覺得 perf 應該是一把世間少有的倚天劍.
金庸筆下的很多人都有對寶刀的癖好, 即便本領低微不配擁有, 但是喜歡, 便無可奈何. 我恐怕正如這些人一樣, 因此進了酒館客棧, 見到相熟或者不相熟的人, 就要興沖沖地要講講那倚天劍的故事.

8 其他Tracer工具

8.1 LTTng

LTTng 是一個 Linux 平臺開源的跟蹤工具, 是一套軟體元件, 可允許跟蹤 Linux 核心和使用者程式, 並控制跟蹤會話(開始/停止跟蹤、啟動/停止事件 等等). 這些元件被繫結如下三個包 :

包	描述
LTTng-tools	庫和用於跟蹤會話的命令列介面
LTTng-modules	允許用 LTTng 跟蹤 Linux 的 Linux 核心模組
LTTng-UST	使用者空間跟蹤庫

8.2 eBPF

extended Berkeley Packet Filter（eBPF）是一個可以在事件上執行程式的高效核心虛擬機器（JIT）。它可能最終會提供 ftrace 和 perf_events 的核心程式設計，並強化其他的 tracer。這是 Alexei Starovoitov 目前正在開發的，還沒有完全整合，但是從4.1開始已經對一些優秀的工具有足夠的核心支援了，如塊裝置I/O的延遲熱圖。可參考其主要作者 Alexei Starovoitov 的BPF slides和eBPF samples。

8.3 Ktap

ktap 在過去是一款前景很好的 tracer，它使用核心中的 lua 虛擬機器處理，在沒有除錯資訊的情況下在嵌入式裝置上執行的很好。它分為幾個步驟，並在有一段時間似乎超過了 Linux 上所有的追蹤器。然後 eBPF 開始進行核心整合，而 ktap 的整合在它可以使用 eBPF 替代它自己的虛擬機器後才開始。因為 eBPF 仍將持續整合幾個月，ktap 開發者要繼續等上一段時間。我希??今年晚些時候它能重新開發。

8.4 dtrace4linux

dtrace4linux 主要是 Paul Fox 一個人在業餘時間完成的，它是 Sun DTrace 的 Linux 版本。它引入矚目，還有一些 provider 可以執行，但是從某種程度上來說還不完整，更多的是一種實驗性的工具（不安全）。我認為，顧忌到許可問題，人們會小心翼翼的為 dtrace4linux 貢獻程式碼：由於當年 Sun 開源DTrace 使用的是 CDDL 協議，而 dtrace4linux 也不大可能最終進入 Linux kernel。Paul 的方法很可能會使其成為一個 add-on。我很樂意看到 Linux 平臺上的 DTrace 和這個專案的完成，我認為當我加入 Netflix 後將會花些時間來協助完成這個專案。然而，我還是要繼續使用內建的 tracers，如 ftrace 和 perf_events。

8.5 OL DTrace

Oracle Linux DTrace為了將 DTrace 引入 Linux，特別是 Oracle Linux，做出了很大的努力。這些年來發布的多個版本表明了它的穩定進展。開發者們以一種對這個專案的前景看好的態度談論著改進 DTrace 測試套件。很多有用的 provider 已經完成了，如：syscall, profile, sdt, proc, sched 以及 USDT。我很期待 fbt（function boundary tracing, 用於核心動態跟蹤）的完成，它是 Linux 核心上非常棒的 provider。OL DTrace 最終的成功將取決於人們對執行 Oracle Linux（為技術支援付費）有多大興趣，另一方面取決於它是否完全開源：它的核心元件是開源的，而我沒有看到它的使用者級別程式碼。

8.6 sysdig

sysdig是一個使用類tcpdump語法來作業系統事件的新tracer，它使用lua提交程序。它很優秀，它見證了系統跟蹤領域的變革。它的侷限性在於它只在當前進行系統呼叫，在提交進行時將所有事件轉儲為使用者級別。你可以使用系統呼叫做很多事情，然而我還是很希望它能支援跟蹤點、kprobe和uprobe。我還期待它能支援eBPF做核心摘要。目前，sysdig開發者正在增加容器支援。留意這些內容。

本作品採用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可, 轉載請註明出處, 謝謝合作.
因本人技術水平和知識面有限, 內容如有紕漏或者需要修正的地方, 歡迎大家指正, 也歡迎大家提供一些其他好的除錯工具以供收錄, 鄙人在此謝謝啦