Linux內核調試的方式以及工具集錦【轉】

轉自：https://blog.csdn.net/gatieme/article/details/68948080

版權聲明：本文爲博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接和本聲明。
本文連接：https://blog.csdn.net/gatieme/article/details/68948080
CSDN GitHub
Linux內核調試的方式以及工具集錦 LDD-LinuxDeviceDrivers/study/debug

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

"調試難度原本就是寫代碼的兩倍. 所以, 若是你寫代碼的時候聰明用盡, 根據定義, 你就沒有能耐去調試它了."
--Brian Kernighan
1
2
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) 數據的文件系統, 它以其功能而得名. 它爲那些須要從內核空間轉發大量數據到用戶空間的工具和應用提供了快速有效的轉發機制.

在 Linux 下用戶空間與內核空間數據交換的方式, 第 2 部分: procfs、seq_file、debugfs和relayfs

Linux 文件系統：procfs, sysfs, debugfs 用法簡介

2.1 procfs文件系統
ProcFs 介紹`
procfs 是比較老的一種用戶態與內核態的數據交換方式, 內核的不少數據都是經過這種方式出口給用戶的, 內核的不少參數也是經過這種方式來讓用戶方便設置的. 除了 sysctl 出口到 /proc 下的參數, procfs 提供的大部份內核參數是隻讀的. 實際上, 不少應用嚴重地依賴於procfs, 所以它幾乎是必不可少的組件. 前面部分的幾個例子實際上已經使用它來出口內核數據, 可是並無講解如何使用, 本節將講解如何使用procfs.

參考資料
用戶空間與內核空間數據交換的方式(2)——procfs

2.2 sysfs文件系統
內核子系統或設備驅動能夠直接編譯到內核, 也能夠編譯成模塊, 編譯到內核, 使用前一節介紹的方法經過內核啓動參數來向它們傳遞參數, 若是編譯成模塊, 則能夠經過命令行在插入模塊時傳遞參數, 或者在運行時, 經過 sysfs 來設置或讀取模塊數據.

Sysfs 是一個基於內存的文件系統, 實際上它基於ramfs, sysfs 提供了一種把內核數據結構, 它們的屬性以及屬性與數據結構的聯繫開放給用戶態的方式, 它與 kobject 子系統緊密地結合在一塊兒, 所以內核開發者不須要直接使用它, 而是內核的各個子系統使用它. 用戶要想使用 sysfs 讀取和設置內核參數, 僅需裝載 sysfs 就能夠經過文件操做應用來讀取和設置內核經過 sysfs 開放給用戶的各個參數：

mkdir -p /sysfs
mount -t sysfs sysfs /sysfs
1
2
注意, 不要把 sysfs 和 sysctl 混淆, sysctl 是內核的一些控制參數, 其目的是方便用戶對內核的行爲進行控制, 而 sysfs 僅僅是把內核的 kobject 對象的層次關係與屬性開放給用戶查看, 所以 sysfs 的絕大部分是隻讀的, 模塊做爲一個 kobject 也被出口到 sysfs, 模塊參數則是做爲模塊屬性出口的, 內核實現者爲模塊的使用提供了更靈活的方式, 容許用戶設置模塊參數在 sysfs 的可見性並容許用戶在編寫模塊時設置這些參數在 sysfs 下的訪問權限, 而後用戶就能夠經過 sysfs 來查看和設置模塊參數, 從而使得用戶能在模塊運行時控制模塊行爲.

用戶空間與內核空間數據交換的方式(6)——模塊參數與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的內核部分不須要作任何改動.

用戶空間與內核空間數據交換的方式(1)——debugfs

Linux內核裏的DebugFS

Linux驅動調試的Debugfs的使用簡介

Linux Debugfs文件系統介紹及使用

Linux內核裏的DebugFS

Debugging the Linux Kernel with debugfs

debugfs-seq_file

Linux Debugfs文件系統介紹及使用

Linux 文件系統：procfs, sysfs, debugfs 用法簡介

用戶空間與內核空間數據交換的方式(1)——debugfs

Linux 運用debugfs調試方法

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.

用戶空間與內核空間數據交換的方式(4)——relayfs

Relay：一種內核到用戶空間的高效數據傳輸技術

2.5 seq_file
通常地, 內核經過在 procfs 文件系統下創建文件來向用戶空間提供輸出信息, 用戶空間能夠經過任何文本閱讀應用查看該文件信息, 可是 procfs 有一個缺陷, 若是輸出內容大於1個內存頁, 須要屢次讀, 所以處理起來很難, 另外, 若是輸出太大, 速度比較慢, 有時會出現一些意想不到的狀況, Alexander Viro 實現了一套新的功能, 使得內核輸出大文件信息更容易, 該功能出如今 2.4.15(包括 2.4.15)之後的全部 2.4 內核以及 2.6 內核中, 尤爲是在 2.6 內核中，已經大量地使用了該功能

用戶空間與內核空間數據交換的方式(3)——seq_file

內核proc文件系統與seq接口（4）—seq_file接口編程淺析

Linux內核中的seq操做

seq_file源碼分析

用序列文件(seq_file)接口導出經常使用數據結構

seq_file機制

3 printk
在內核調試技術之中, 最簡單的就是 printk 的使用了, 它的用法和C語言應用程序中的 printf 使用相似, 在應用程序中依靠的是 stdio.h 中的庫, 而在 linux 內核中沒有這個庫, 因此在 linux 內核中, 實現了本身的一套庫函數, printk 就是標準的輸出函數

linux內核調試技術之printk

調整內核printk的打印級別

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 將不斷被加入內核。

ftrace和它的前端工具trace-cmd(深刻了解Linux系統的利器)

ftrace 簡介

內核性能調試–ftrace

使用 ftrace 調試 Linux 內核，第 1 部分

ftrace的使用

[轉]Linux內核跟蹤之trace框架分析

Linux trace使用入門

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
1
2
3
4
5
trace-cmd: A front-end for Ftrace

其本質就是對/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 則是在指定的內核函數返回時才被執行.

kprobe工做原理

隨想錄(強大的kprobe)

kprobe原理解析（一）

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 等.

這些解決方案在功能上都是相似的, 在觸發探針時使用探針和相關聯的操做腳本.

SystemTap 學習筆記 - 安裝篇

Linux 自檢和 SystemTap 用於動態內核分析的接口和語言

Brendan’s blog Using SystemTap

內核調試神器SystemTap — 簡介與使用（一）

內核探測工具systemtap簡介

SystemTap Beginner

使用systemtap調試linux內核

Ubuntu Kernel Debuginfo

Linux 下的一個全新的性能測量和調式診斷工具 Systemtap, 第 3 部分: Systemtap

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
1
就能夠運行 kdb 的 ps 命令了.

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

kdb跟 kgdb 合併以後, 也可使用 kgdb 的IO 驅動(好比鍵盤), 可是同時也 kdb也喪失了一些功能. 合併以後的kdb不在支持彙編級的源碼調試. 所以它如今也是平臺獨立的.

kdump和kexec已經被移除。

從/proc/meninfo中獲取的信息比之前少了。

bt命令如今使用的是內核的backtracer，而不是kdb原來使用的反彙編。

合併以後的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.

即便板子上沒有 GDB 並且其沒有可用的遠程接口, KGTP 也能夠用離線調試的功能調試內核（見http://code.google.com/p/kgtp/wiki/HOWTOCN#/sys/kernel/debug/gtpframe和離線調試）。

KGTP支持 X86-32 ， X86-64 ， MIPS 和 ARM 。
KGTP在Linux內核 2.6.18到upstream 上都被測試過。
並且還能夠用在 Android 上(見 HowToUseKGTPinAndroid)

github-KGTP

KGTP內核調試使用

KGTP中增長對GDB命令「set trace-buffer-size」的支持 - Week 5

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 應該是一把世間少有的倚天劍.
金庸筆下的不少人都有對寶刀的癖好, 即使本領低微不配擁有, 可是喜歡, 便迫不得已. 我恐怕正如這些人同樣, 所以進了酒館客棧, 見到相熟或者不相熟的人, 就要興沖沖地要講講那倚天劍的故事.

Perf – Linux下的系統性能調優工具，第 1 部分

perf Examples

改進版的perf, Performance analysis tools based on Linux perf_events (aka perf) and ftrace

Perf使用教程

linux下的內核測試工具——perf使用簡介

perf 移植

8 其餘Tracer工具
8.1 LTTng
LTTng 是一個 Linux 平臺開源的跟蹤工具, 是一套軟件組件, 可容許跟蹤 Linux 內核和用戶程序, 並控制跟蹤會話(開始/中止跟蹤、啓動/中止事件 等等). 這些組件被綁定以下三個包 :

包 描述
LTTng-tools 庫和用於跟蹤會話的命令行接口
LTTng-modules 容許用 LTTng 跟蹤 Linux 的 Linux 內核模塊
LTTng-UST 用戶空間跟蹤庫

Linux 平臺開源的跟蹤工具：LTTng

用 lttng 跟蹤內核

LTTng and LTTng project

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 國際許可協議進行許可, 轉載請註明出處, 謝謝合做. 因本人技術水平和知識面有限, 內容若有紕漏或者須要修正的地方, 歡迎你們指正, 也歡迎你們提供一些其餘好的調試工具以供收錄, 鄙人在此謝謝啦————————————————版權聲明：本文爲CSDN博主「JeanCheng」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/gatieme/article/details/68948080