當前位置: 妍妍網 > 碼農

Linux內核的經典偵錯方式

2024-02-21碼農

點選上方Linux開源社群」,選擇「設為星標

優質文章,及時送達

原文作者:CHENG Jian

原文連結:https://kernel.blog.csdn.net/article/details/68948080

1 內核偵錯以及工具總結

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

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

2 使用者空間與內核空間數據交換的檔案系統

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

它們都用於Linux內核和使用者空間的數據交換, 但是適用的場景有所差異:

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

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

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

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

  • 相關資料連結:

    在 Linux 下使用者空間與內核空間數據交換的方式, 第 2 部份: procfs、seq_file、debugfs和relayfs:http://www.ibm.com/developerworks/cn/linux/l-kerns-usrs2/

    Linux 檔案系統:procfs, sysfs, debugfs 用法簡介:http://www.tinylab.org/show-the-usage-of-procfs-sysfs-debugfs/

    2.1 procfs檔案系統

  • ProcFs 介紹

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

  • 參考資料:

    使用者空間與內核空間數據交換的方式(2)——procfs:http://www.cnblogs.com/hoys/archive/2011/04/10/2011141.html

  • 2.2 sysfs檔案系統

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

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

    mkdir-p /sysfsmount-t sysfs sysfs /sysfs

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

    相關資料連結:

    使用者空間與內核空間數據交換的方式(6)——模組參數與sysfs:http://www.cnblogs.com/hoys/archive/2011/04/10/2011470.html

    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:http://www.cnblogs.com/hoys/archive/2011/04/10/2011124.html

    Linux內核裏的DebugFS:http://www.cnblogs.com/wwang/archive/2011/01/17/1937609.html

    Linux驅動偵錯的Debugfs的使用簡介:http://soft.chinabyte.com/os/110/12377610.shtml

    Linux Debugfs檔案系統介紹及使用:http://blog.sina.com.cn/s/blog_40d2f1c80100p7u2.html

    Linux內核裏的DebugFS:http://www.cnblogs.com/wwang/archive/2011/01/17/1937609.html

    Debugging the Linux Kernel with debugfs:http://opensourceforu.com/2010/10/debugging-linux-kernel-with-debugfs/

    debugfs-seq_file:http://lxr.free-electrons.com/source/drivers/base/power/wakeup.c

    Linux Debugfs檔案系統介紹及使用:http://blog.sina.com.cn/s/blog_40d2f1c80100p7u2.html

    Linux 檔案系統:procfs, sysfs, debugfs 用法簡介:http://www.tinylab.org/show-the-usage-of-procfs-sysfs-debugfs/

    使用者空間與內核空間數據交換的方式(1)——debugfs:http://www.cnblogs.com/hoys/archive/2011/04/10/2011124.html

    Linux 運用debugfs偵錯方法:http://www.xuebuyuan.com/1023006.html

    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

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

    相關資料連結:

    使用者空間與內核空間數據交換的方式(4)——relayfs:http://www.cnblogs.com/hoys/archive/2011/04/10/2011270.html

    Relay:一種內核到使用者空間的高效數據傳輸技術:https://www.ibm.com/developerworks/cn/linux/l-cn-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:http://www.cnblogs.com/hoys/archive/2011/04/10/2011261.html

    內核proc檔案系統與seq介面(4)—seq_file介面編程淺析:http://blog.chinaunix.net/uid-20543672-id-3235254.html

    Linux內核中的seq操作:http://www.cnblogs.com/qq78292959/archive/2012/06/13/2547335.html

    seq_file源分碼析:http://www.cppblog.com/csjiaxin/articles/136681.html

    用序列檔(seq_file)介面匯出常用數據結構:http://blog.chinaunix.net/uid-317451-id-92670.html

    seq_file機制:http://blog.csdn.net/a8039974/article/details/24052619

    3 printk

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

    相關資料連結:

    linux內核偵錯技術之printk:http://www.cnblogs.com/veryStrong/p/6218383.html

    調整內核printk的打印級別:http://blog.csdn.net/tonywgx/article/details/17504001

    linux裝置驅動學習筆記–內核偵錯方法之printk:http://blog.csdn.net/itsenlin/article/details/43205983

    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 , ftrace 是目前非常活躍的開發領域, 新的 tracer 將不斷被加入內核。

    相關資料連結:

    ftrace和它的前端工具trace-cmd(深入了解Linux系統的利器):http://blog.yufeng.info/archives/1012

    ftrace 簡介:https://www.ibm.com/developerworks/cn/linux/l-cn-ftrace/

    內核效能偵錯–ftrace:http://blog.chinaunix.net/uid-20589411-id-3501525.html

    使用 ftrace 偵錯 Linux 內核,第 1 部份:https://www.ibm.com/developerworks/cn/linux/l-cn-ftrace1

    ftrace的使用:http://blog.csdn.net/cybertan/article/details/8258394

    [轉]Linux內核跟蹤之trace框架分析:http://blog.chinaunix.net/uid-24063584-id-2642103.html

    Linux trace使用入門:http://blog.csdn.net/jscese/article/details/46415531

    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

    trace-cmd: A front-end for Ftrace:https://lwn.net/Articles/410200/

    其本質就是對 /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工作原理:http://blog.itpub.net/15480802/viewspace-1162094/

    隨想錄(強大的kprobe):http://blog.csdn.net/feixiaoxing/article/details/40351811

    kprobe原理解析(一):http://www.cnblogs.com/honpey/p/4575928.html

    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 學習筆記 - 安裝篇:https://segmentfault.com/a/1190000000671438

    Linux 自檢和 SystemTap 用於動態內核分析的介面和語言:https://www.ibm.com/developerworks/cn/linux/l-systemtap/

    Brendan’s blog Using SystemTap:http://dtrace.org/blogs/brendan/2011/10/15/using-systemtap/

    內核偵錯神器SystemTap — 簡介與使用(一):http://blog.csdn.net/zhangskd/article/details/25708441

    內核探測工具systemtap簡介:http://www.cnblogs.com/hazir/p/systemtap_introduction.html

    SystemTap Beginner:http://blog.csdn.net/kafeiflynn/article/details/6429976

    使用systemtap偵錯linux內核:http://blog.csdn.net/heli007/article/details/7187748

    Ubuntu Kernel Debuginfo:http://ddebs.ubuntu.com/pool/main/l/linux

    Linux 下的一個全新的效能測量和調式診斷工具 Systemtap, 第 3 部份: Systemtap:https://www.ibm.com/developerworks/cn/linux/l-cn-systemtap3/

    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 .

    即使板子上沒有 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 上(見 http://code.google.com/p/kgtp/wiki/HowToUseKGTPinAndroid )

    相關資料連結:

    github-KGTP:https://github.com/teawater/kgtp

    KGTP內核偵錯使用:http://blog.csdn.net/djinglan/article/details/15335653

    KGTP中增加對GDB命令「set trace-buffer-size」的支持 - Week 5:http://blog.csdn.net/calmdownba/article/details/38659317

    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 部份:https://www.ibm.com/developerworks/cn/linux/l-cn-perf1/index.html

    perf Examples:http://www.brendangregg.com/perf.html

    改進版的perf, Performance analysis tools based on Linux perf_events (aka perf) and ftrace:https://github.com/brendangregg/perf-tools

    Perf使用教程:http://blog.chinaunix.net/uid-10540984-id-3854969.html

    linux下的內核測試工具——perf使用簡介:http://blog.csdn.net/trochiluses/article/details/10261339

    perf 移植:http://www.cnblogs.com/helloworldtoyou/p/5585152.html

    8 其他Tracer工具

    8.1 LTTng

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

    相關資料連結:

    Linux 平台開源的跟蹤工具:LTTng:http://www.open-open.com/lib/view/open1413946397247.html

    用 lttng 跟蹤內核:http://blog.csdn.net/xsckernel/article/details/17794551

    LTTng and LTTng project:http://blog.csdn.net/ganggexiongqi/article/details/6664331

    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開發者正在增加容器支持。留意這些內容。

    -End-

    讀到這裏說明你喜歡本公眾號的文章,歡迎 置頂(標星)本公眾號 Linux技術迷,這樣就可以第一時間獲取推播了~

    本公眾號,後台回復:Linux,領取2T學習資料 !

    1. 

    2. 

    3.

    4.