射死你天天日,五月花视频,天天色啪,国产成人综合欧美精品久久,亚洲无码在线免费观看视频吗? ,在现男人XX女人视频,www.污污在线观看,少妇性受XXXX黑人XYX性爽

1. 位置無關(guān)碼

加載地址：存儲(chǔ)代碼的物理地址。如ARM64處理器上電復(fù)位后是從0x0地址開始第一條指令的，所以通常這個(gè)地方存放代碼最開始的部分，如異常向量表的處理地址
運(yùn)行地址：指程序運(yùn)行時(shí)的地址
鏈接地址：在編譯鏈接時(shí)指定的地址，編程人員設(shè)想將來程序要運(yùn)行的地址。程序所有標(biāo)號的地址在鏈接后便確定了，不管程序在哪里運(yùn)行都不會(huì)改變。aarch64-linux-gnu-obidump (objdump)工具進(jìn)行反匯編查看的就接地鏈接地址

鏈接地址和運(yùn)行地址可以相同，也可以不同。那什么時(shí)候運(yùn)行地址和鏈接地址不相同，什么時(shí)候相同呢？我們以一塊ARM64開發(fā)板為例，芯片內(nèi)部有SRAM，起始地址為0x0，DDR內(nèi)存的起始地址為0x4000 0000。

通常代碼存儲(chǔ)在 Nor Flash存儲(chǔ)器或者 Nand Flash存儲(chǔ)器中，芯片內(nèi)部的 BOOT ROM會(huì)把開始的小部分代碼裝載到SRAM中運(yùn)行。芯片上電復(fù)位之后，從SRAM中取指令。由于 Uboot的鏡像太大了，SRAM放不下，因此必須要放在DDR內(nèi)存中。通常Uboot編譯時(shí)鏈接地址都沒置到DDR內(nèi)存中，也就是0x4000 0000地址處。那這時(shí)運(yùn)行地址和鏈接地址就不一樣了。運(yùn)行地址為0x0，鏈接地址變成了0x4000 0000那么程序?yàn)槭裁催€能運(yùn)行呢個(gè)重要問題，就是位置無關(guān)代碼和位置有關(guān)代碼。

位置無關(guān)代碼：從字面意思看，該指令的執(zhí)行是與內(nèi)存地址無關(guān)的；無論運(yùn)行地址和鏈接地址相等或者不相等，該指令都能正常運(yùn)行。在匯編語言中，像BL、B、MOV指令屬于位置無關(guān)指令，不管程序裝載在哪個(gè)位置，它們都能正確地運(yùn)行，它們的地址域是基于PC值的相對偏移尋址，相當(dāng)于[pc+offset]
位置有關(guān)代碼：從字面意思看，該指令的執(zhí)行是與內(nèi)存地址有關(guān)的，和當(dāng)前PC值無關(guān)。ARM匯編里面通過絕對跳轉(zhuǎn)修改PC值為當(dāng)前鏈接地址的值

1	ldr pc, = on_sdram ;跳到 SDRAM中繼續(xù)執(zhí)行

因此，當(dāng)通過LDR指令跳轉(zhuǎn)到鏈接地址處執(zhí)行時(shí)，運(yùn)行地址就等于鏈接地址了。這個(gè)過程叫作“重定位”。在重定位之前，程序只能執(zhí)行和位置無關(guān)的一些匯編代碼。為什么要刻意設(shè)置加載地址、運(yùn)行地址以及鏈接地址不一樣呢？如果所有代碼都在ROM（或 Nor Flash存儲(chǔ)器）中執(zhí)行，那么鏈接地址可以與加載地址相同；而在實(shí)際項(xiàng)目應(yīng)用中，往往想要把程序加載到DDR內(nèi)存中，DDR內(nèi)存的訪問速度比ROM要快很多，而且容量也大。但是礙于加載地址的影響，不可能直接達(dá)到這一步，所以思路就是讓程序的加載地址等于ROM起始地址，而鏈接地址等于DDR內(nèi)存中某一處的起始地址（暫且稱為 ram start）。程序先從ROM中啟動(dòng)，最先啟動(dòng)的部分要實(shí)現(xiàn)代碼復(fù)制功能（把整個(gè)ROM代碼復(fù)制到DDR內(nèi)存中），并通過LDR指令來跳轉(zhuǎn)到DDR內(nèi)存中，也就是在鏈接地址里運(yùn)行B指令沒法實(shí)現(xiàn)這個(gè)跳轉(zhuǎn)）。上述重定位過程在U-Boot中實(shí)現(xiàn)，如圖所示。

當(dāng)跳轉(zhuǎn)到 Linux內(nèi)核中時(shí)，U-Boot需要把 Linux內(nèi)核映像內(nèi)容復(fù)制到DDR內(nèi)存中，然后跳轉(zhuǎn)到內(nèi)核入口地址處（ stext函數(shù)）。當(dāng)跳轉(zhuǎn)到內(nèi)核入口地址（ stext函數(shù)）時(shí)，程序運(yùn)行在運(yùn)行地址，即DDR內(nèi)存的地址。但是我們從 vmlinux看到的 stext 函數(shù)的鏈接地址是虛擬地址（內(nèi)核啟動(dòng)匯編代碼也需要一個(gè)重定位過程。這個(gè)重定位過程在__primary_switch()匯編函數(shù)中完成。啟動(dòng)MMU之后，通過ldr指令把 __primary_switched()函數(shù)的鏈接地址加載到x8寄存器，然后通過br指令跳轉(zhuǎn)到 __primary_switched()函數(shù)的鏈接地址處，從而實(shí)現(xiàn)了重定位，如圖所示

<arch/arm64/kernel/head.S>
/*
 * The following fragment of code is executed with the MMU enabled.
 *
 *   x0 = __PHYS_OFFSET
 */
SYM_FUNC_START_LOCAL(__primary_switched)
  adr_l	x4, init_task
  init_cpu_task x4, x5, x6

  adr_l	x8, vectors			// load VBAR_EL1 with virtual
  msr	vbar_el1, x8			// vector table address
  isb

  stp	x29, x30, [sp, #-16]!
  mov	x29, sp

  str_l	x21, __fdt_pointer, x5		// Save FDT pointer

  ldr_l	x4, kimage_vaddr		// Save the offset between
  sub	x4, x4, x0			// the kernel virtual and
  str_l	x4, kimage_voffset, x5		// physical mappings

  // Clear BSS
  adr_l	x0, __bss_start
  mov	x1, xzr
  adr_l	x2, __bss_stop
  sub	x2, x2, x0
  bl	__pi_memset
  dsb	ishst				// Make zero page visible to PTW

#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
  bl	kasan_early_init
#endif
  mov	x0, x21				// pass FDT address in x0
  bl	early_fdt_map			// Try mapping the FDT early
  bl	init_feature_override		// Parse cpu feature overrides
#ifdef CONFIG_RANDOMIZE_BASE
  tst	x23, ~(MIN_KIMG_ALIGN - 1)	// already running randomized?
  b.ne	0f
  bl	kaslr_early_init		// parse FDT for KASLR options
  cbz	x0, 0f				// KASLR disabled? just proceed
  orr	x23, x23, x0			// record KASLR offset
  ldp	x29, x30, [sp], #16		// we must enable KASLR, return
  ret					// to __primary_switch()
0:
#endif
  bl	switch_to_vhe			// Prefer VHE if possible
  ldp	x29, x30, [sp], #16
  bl	start_kernel
  ASM_BUG()
SYM_FUNC_END(__primary_switched)

2. ftrace

frace最早出現(xiàn)在 Linux2.6.27內(nèi)核中，其設(shè)計(jì)目標(biāo)簡單，基于靜態(tài)代碼插樁（stub）技術(shù)，不需要用戶通過額外的編程來定義 trace行為。靜態(tài)代碼插樁技術(shù)比較可靠，不會(huì)因?yàn)橛脩羰褂貌划?dāng)而導(dǎo)致內(nèi)核崩潰。ftrace 的名字源于 function trace利用GCC的 profile特性在所有函數(shù)入口處添加一段插樁代碼， ftrace重載這段代碼來實(shí)現(xiàn) trace 功能。GCC的-pg選項(xiàng)會(huì)在每個(gè)函數(shù)入口處加入 mcount的調(diào)用代碼，原本 mcount有l(wèi)ibc實(shí)現(xiàn)，而內(nèi)核不會(huì)鏈接libc庫，因此frace編寫了自己的mcount stub函數(shù)。在使用ftrace之前，需要確保內(nèi)核編譯配置選項(xiàng)。

CONFIG_FTRACE=y
ONIFIG_HAVE_FUNCTION_TRACE=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_FUNCTIONL_TRACER=y
CONFIG_IRQSOFE_TRACER=Y
CONEIG_SCHED_TRACER=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_PREEMPT_TRACER=y

ftrace的相關(guān)配置選項(xiàng)比較多，針對不同的跟蹤器有各自對應(yīng)的配置選項(xiàng)。ftrace通過debugfs文件系統(tǒng)向用戶空間提供訪間接口，因此需要在系統(tǒng)啟動(dòng)時(shí)掛載 debugfs，可以修改系統(tǒng)的 /etc/fstab文件或手動(dòng)掛載。

1	mount -t debugfs debugfs/sys/kernel/debug

在 sys/kernel/debug/trace目錄下提供了各種跟蹤器（ tracer）和事件（ event），一些常用的選項(xiàng)如下。

available_tracers：列出當(dāng)前系統(tǒng)支持的跟蹤器
available_events：列出當(dāng)前系統(tǒng)支持的事件
current_tracer：設(shè)置和顯示當(dāng)前正在使用的跟蹤器。使用echo命令把跟蹤器的名字寫入該文件，即可切換不同的跟蹤器。默認(rèn)為nop，即不做任何跟蹤操作
trace: 讀取跟蹤信息。通過cat命令查看 ftrace記錄下來的眼蹤信息
tracing_on：用于開始或暫停跟蹤
trace_options：設(shè)置 ftrace的一些相關(guān)選項(xiàng)

ftrace當(dāng)前包含多個(gè)跟蹤器，方便用戶跟蹤不同類型的信息，如進(jìn)程睡眠、喚醒、搶占、延遲的信息。查看 available_tracers可以知道當(dāng)前系統(tǒng)支持哪些跟蹤器，如果系統(tǒng)支持的跟蹤器上沒有用戶想要的。那就必須在配置內(nèi)核時(shí)打開，然后重新編譯內(nèi)核。常用的ftrace跟蹤器如下所示：

nop：不跟蹤任何信息。將nop寫入current_tracer文件可以清空之前收集到的跟蹤信息
function：跟蹤內(nèi)核函數(shù)執(zhí)行情況
function_graph：可以顯示類似于C語言的函數(shù)調(diào)用關(guān)系圖，比較直觀
hwlat：用來跟蹤與硬件相關(guān)的延時(shí)
blk：跟蹤塊設(shè)備的函數(shù)
mmiotrace：用于跟蹤內(nèi)存映射I/O操作
wakeup：跟蹤普通優(yōu)先級的進(jìn)程從獲得調(diào)度到被喚醒的最長延遲時(shí)間
weakup_rt：跟蹤RT類型的任務(wù)從獲得調(diào)度到被喚醒的最長延遲時(shí)間
irqoff：跟蹤關(guān)閉中斷的信息，并記錄關(guān)閉的最大時(shí)長
preemptoff：跟蹤關(guān)閉禁止搶占的信息，并記錄關(guān)閉的最大時(shí)長

3. irqs跟蹤器

當(dāng)中斷關(guān)閉（俗稱關(guān)中斷）后，CPU就不能響應(yīng)其他的事件。如果這時(shí)有一個(gè)鼠標(biāo)中斷，要在下一次開中斷時(shí)才能響應(yīng)這個(gè)中斷，這段延時(shí)稱為中斷延遲。向current_tracer文件寫入 irqsoff字符串即可打開 irqsoff來跟蹤中斷延遲。

cd /sys/kernel/debug/tracing/
echo 0 > options/function-trace //關(guān)閉 funct-trace可以減少一些延退
echo irqsoff > current_trace
echo 1 > tracing_on 
[...] //停頓一會(huì)兒
echo 0 > tracing_on
cat trace

4. Function tracing - no modification necessary

Ftrace 最強(qiáng)大的追蹤器之一是函數(shù)追蹤器。它使用gcc的-pg選項(xiàng)讓內(nèi)核中的每個(gè)函數(shù)調(diào)用一個(gè)特殊的函數(shù)“ mcount() ”。該函數(shù)必須在匯編中實(shí)現(xiàn)，因?yàn)檎{(diào)用不遵循正常的 C ABI。

當(dāng)配置 CONFIG_DYNAMIC_FTRACE 時(shí)，調(diào)用會(huì)在啟動(dòng)時(shí)轉(zhuǎn)換為 NOP，以保持系統(tǒng)以 100% 的性能運(yùn)行。在編譯過程中，記錄了 mcount() 調(diào)用站點(diǎn)。該列表在啟動(dòng)時(shí)用于將這些站點(diǎn)轉(zhuǎn)換為 NOP。由于 NOP 對跟蹤毫無用處，因此當(dāng)啟用函數(shù)（或函數(shù)圖）跟蹤器時(shí)，保存該列表以將調(diào)用站點(diǎn)轉(zhuǎn)換回跟蹤調(diào)用。

由于此性能增強(qiáng)，強(qiáng)烈建議啟用 CONFIG_DYNAMIC_FTRACE。此外，CONFIG_DYNAMIC_FTRACE 提供了篩選應(yīng)跟蹤哪個(gè)函數(shù)的能力。請注意，即使 NOP 在基準(zhǔn)測試中沒有顯示任何影響，但已知添加-pg選項(xiàng)附帶的幀指針會(huì)導(dǎo)致輕微的開銷。

要找出哪些跟蹤器可用，只需在跟蹤目錄中查找available_tracers文件即可：

1 2	[tracing]# cat available_tracers function_graph function sched_switch nop

要啟用函數(shù)跟蹤器，只需將“function” echo 到 current_tracer文件中。

[tracing]# echo function > current_tracer
[tracing]# cat current_tracer
function

[tracing]# cat trace | head -10
# tracer: function
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
            bash-16939 [000]  6075.461561: mutex_unlock <-tracing_set_tracer
          <idle>-0     [001]  6075.461561: _spin_unlock_irqrestore <-hrtimer_get_next_event
          <idle>-0     [001]  6075.461562: rcu_needs_cpu <-tick_nohz_stop_sched_tick
            bash-16939 [000]  6075.461563: inotify_inode_queue_event <-vfs_write
          <idle>-0     [001]  6075.461563: mwait_idle <-cpu_idle
            bash-16939 [000]  6075.461563: __fsnotify_parent <-vfs_write

標(biāo)題很好地解釋了輸出的格式。前兩項(xiàng)是跟蹤的任務(wù)名稱和 PID。執(zhí)行跟蹤的 CPU 位于括號內(nèi)。時(shí)間戳是自啟動(dòng)以來的時(shí)間，后跟函數(shù)名稱。在這種情況下，函數(shù)是被跟蹤的函數(shù)，其父函數(shù)跟在“ <- ”符號之后。

這些信息非常強(qiáng)大，并且很好地顯示了函數(shù)的流程。但這可能有點(diǎn)難以遵循。由 Frederic Weisbecker 創(chuàng)建的函數(shù)圖跟蹤器跟蹤函數(shù)的進(jìn)入和退出，這使跟蹤器能夠了解被調(diào)用函數(shù)的深度。函數(shù)圖跟蹤器可以使人眼更容易跟蹤內(nèi)核中的執(zhí)行流程：

[tracing]# echo function_graph > current_tracer 
[tracing]# cat trace | head -20
# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 1)   1.015 us    |        _spin_lock_irqsave();
 1)   0.476 us    |        internal_add_timer();
 1)   0.423 us    |        wake_up_idle_cpu();
 1)   0.461 us    |        _spin_unlock_irqrestore();
 1)   4.770 us    |      }
 1)   5.725 us    |    }
 1)   0.450 us    |    mutex_unlock();
 1) + 24.243 us   |  }
 1)   0.483 us    |  _spin_lock_irq();
 1)   0.517 us    |  _spin_unlock_irq();
 1)               |  prepare_to_wait() {
 1)   0.468 us    |    _spin_lock_irqsave();
 1)   0.502 us    |    _spin_unlock_irqrestore();
 1)   2.411 us    |  }
 1)   0.449 us    |  kthread_should_stop();
 1)               |  schedule() {

這給出了一個(gè)函數(shù)的開始和結(jié)束，用類似 C 的注釋“ { ”來啟動(dòng)一個(gè)函數(shù)，“ } ”在末尾。葉函數(shù)不調(diào)用其他函數(shù)，只是以“ ; ”結(jié)尾。DURATION 列顯示在相應(yīng)函數(shù)中花費(fèi)的時(shí)間。函數(shù)圖跟蹤器記錄函數(shù)進(jìn)入和退出的時(shí)間，并將差異報(bào)告為持續(xù)時(shí)間。這些數(shù)字只出現(xiàn)在葉函數(shù)和“ }" 符號。注意，這次還包括嵌套函數(shù)內(nèi)所有函數(shù)的開銷以及函數(shù)圖跟蹤器本身的開銷。函數(shù)圖跟蹤器劫持了函數(shù)的返回地址，以便為函數(shù)插入跟蹤回調(diào)函數(shù)退出。這會(huì)破壞 CPU 的分支預(yù)測并導(dǎo)致比函數(shù)跟蹤器更多的開銷。最接近的真實(shí)時(shí)序僅發(fā)生在葉函數(shù)中。

孤獨(dú)的“ + ”是有一個(gè)注釋標(biāo)記。當(dāng)持續(xù)時(shí)間大于 10 微秒時(shí)，顯示“ + ”。如果持續(xù)時(shí)間大于 100 微秒，將顯示“ ！”。

5. Using trace_printk()

printk()是所有調(diào)試器之王，但它有一個(gè)問題。如果您正在調(diào)試諸如定時(shí)器中斷、調(diào)度程序或網(wǎng)絡(luò)之類的大容量區(qū)域，printk()可能會(huì)導(dǎo)致系統(tǒng)陷入困境，甚至可能會(huì)創(chuàng)建實(shí)時(shí)鎖。添加一些printk()時(shí)，看到錯(cuò)誤“消失”也很常見。這是由于printk()引入的絕對開銷。

Ftrace 引入了一種新形式的printk()稱為 trace_printk()。它可以像printk()一樣使用，也可以在任何上下文中使用（中斷代碼、NMI 代碼和調(diào)度程序代碼）。是什么樣的好的trace_printk()是，它不會(huì)輸出到控制臺(tái)。相反，它寫入 Ftrace 環(huán)形緩沖區(qū)，并且可以通過跟蹤文件讀取。

使用trace_printk()寫入環(huán)形緩沖區(qū)只需要大約十分之一微秒左右。但是使用printk()，尤其是在寫入串行控制臺(tái)時(shí)，每次寫入可能需要幾毫秒。trace_printk()的性能優(yōu)勢使您可以記錄內(nèi)核中最敏感的區(qū)域，而幾乎沒有影響。

例如，您可以將這樣的內(nèi)容添加到內(nèi)核或模塊中：

1	trace_printk("read foo %d out of bar %p\n", bar->foo, bar);

然后通過查看跟蹤文件，您可以看到您的輸出。

[tracing]# cat trace
# tracer: nop
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
           <...>-10690 [003] 17279.332920: : read foo 10 out of bar ffff880013a5bef8

上面的示例是通過添加一個(gè)實(shí)際上具有foo和bar構(gòu)造的模塊來完成的。

trace_printk()輸出將出現(xiàn)在任何跟蹤器中，甚至是函數(shù)和函數(shù)圖跟蹤器。

[tracing]# echo function_graph > current_tracer
[tracing]# insmod ~/modules/foo.ko
[tracing]# cat trace
# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 3) + 16.283 us   |      }
 3) + 17.364 us   |    }
 3)               |    do_one_initcall() {
 3)               |      /* read foo 10 out of bar ffff88001191bef8 */
 3)   4.221 us    |    }
 3)               |    __wake_up() {
 3)   0.633 us    |      _spin_lock_irqsave();
 3)   0.538 us    |      __wake_up_common();
 3)   0.563 us    |      _spin_unlock_irqrestore();

是的，trace_printk() 輸出看起來像函數(shù)圖跟蹤器中的注釋。

6. Starting and stopping the trace

顯然，有時(shí)您只想跟蹤特定的代碼路徑。也許您只想跟蹤運(yùn)行特定測試時(shí)發(fā)生的情況。文件tracing_on用于禁止環(huán)形緩沖區(qū)記錄數(shù)據(jù)：

1	[tracing]# echo 0 > tracking_on

這將禁用 Ftrace 環(huán)形緩沖區(qū)的記錄。其他所有事情仍然發(fā)生在跟蹤器上，它們?nèi)匀粫?huì)產(chǎn)生大部分開銷。他們確實(shí)注意到環(huán)形緩沖區(qū)沒有記錄，也不會(huì)嘗試寫入任何數(shù)據(jù)，但仍會(huì)執(zhí)行跟蹤器發(fā)出的調(diào)用。

要重新啟用環(huán)形緩沖區(qū)，只需將“1”寫入該文件：

1	[tracing]# echo 1 >tracing_on

請注意，在數(shù)字和大于號“ > ”之間有一個(gè)空格非常重要。否則，您可能正在將標(biāo)準(zhǔn)輸入或輸出寫入該文件。

1	[tracing]# echo 0>tracing_on /* 這行不通！*/

一個(gè)常見的運(yùn)行可能是：

1
2
3

[tracing]# echo 0 > tracing_on
[tracing]# echo function_graph > current_tracer
[tracing]# echo 1 > tracing_on; run_test; echo 0 > tracing_on

第一行禁止環(huán)形緩沖區(qū)記錄任何數(shù)據(jù)。接下來啟用函數(shù)圖跟蹤器。函數(shù)圖跟蹤器的開銷仍然存在，但不會(huì)將任何內(nèi)容記錄到跟蹤緩沖區(qū)中。最后一行啟用環(huán)形緩沖區(qū)，運(yùn)行測試程序，然后禁用環(huán)形緩沖區(qū)。這縮小了函數(shù)圖跟蹤器存儲(chǔ)的數(shù)據(jù)范圍，以僅包括run_test程序積累的數(shù)據(jù) 。

7. Trace Markers

查看內(nèi)核內(nèi)部發(fā)生的事情可以讓用戶更好地了解他們的系統(tǒng)是如何工作的。但有時(shí)需要在用戶空間發(fā)生的事情和內(nèi)核內(nèi)部發(fā)生的事情之間進(jìn)行協(xié)調(diào)。跟蹤中顯示的時(shí)間戳都與跟蹤中發(fā)生的事情有關(guān)，但它們與墻時(shí)間不太對應(yīng)。

為了幫助同步用戶空間和內(nèi)核空間中的操作，創(chuàng)建了trace_marker文件。它提供了一種從用戶空間寫入 Ftrace 環(huán)形緩沖區(qū)的方法。該標(biāo)記隨后將出現(xiàn)在軌跡中，以給出軌跡中特定事件發(fā)生的位置。

[tracing]# echo hello world > trace_marker
[tracing]# cat trace
# tracer: nop
#
#           TASK-PID    CPU#    TIMESTAMP  FUNCTION
#              | |       |          |         |
           <...>-3718  [001]  5546.183420: 0: hello world

在<...>表示該寫的標(biāo)記任務(wù)的名字沒有記錄。未來的版本可能會(huì)解決這個(gè)問題。

8. Starting, Stopping and Recording in a Program

該tracing_on和trace_marker 文件的工作很好地跟蹤應(yīng)用程序的活動(dòng)，如果應(yīng)用程序的源可用。如果應(yīng)用程序中存在問題并且您需要找出應(yīng)用程序特定位置的內(nèi)核內(nèi)部發(fā)生了什么，這兩個(gè)文件就派上用場了。

在應(yīng)用程序啟動(dòng)時(shí)，您可以打開這些文件以準(zhǔn)備好文件描述符：

int trace_fd = -1;
int marker_fd = -1;

int main(int argc, char **argv)
{
 char *debugfs;
 char path[256];
 [...]

 debugfs = find_debugfs();
 if (debugfs) {
  strcpy(path, debugfs);  /* BEWARE buffer overflow */
  strcat(path,"/tracing/tracing_on");
  trace_fd = open(path, O_WRONLY);
  if (trace_fd >= 0)
   write(trace_fd, "1", 1);

  strcpy(path, debugfs);
  strcat(path,"/tracing/trace_marker");
  marker_fd = open(path, O_WRONLY);

然后，在代碼中的某個(gè)關(guān)鍵位置，可以放置標(biāo)記以顯示應(yīng)用程序當(dāng)前所在的位置：

if (marker_fd >= 0)
 write(marker_fd, "In critical area\n", 17);

if (critical_function() < 0) {
 /* we failed! */
 if (trace_fd >= 0)
  write(trace_fd, "0", 1);
}

在查看示例時(shí)，您首先會(huì)看到一個(gè)名為“find_debugfs()”的函數(shù)。掛載調(diào)試文件系統(tǒng)的正確位置是/sys/kernel/debug但強(qiáng)大的工具不應(yīng)依賴于掛載在那里的調(diào)試文件系統(tǒng)。find_debugfs()的示例位于此處。文件描述符被初始化為 -1 以允許此代碼在啟用和不啟用跟蹤的內(nèi)核的情況下工作。

當(dāng)檢測到問題時(shí)，將 ASCII 字符“0”寫入trace_fd文件描述符將停止跟蹤。正如在第 1 部分中討論的那樣，這只會(huì)禁用記錄到 Ftrace 環(huán)形緩沖區(qū)中，但跟蹤器仍然會(huì)產(chǎn)生開銷。

使用上面的初始化代碼時(shí)，跟蹤將在應(yīng)用程序開始時(shí)啟用，因?yàn)楦櫰饕愿采w模式運(yùn)行。也就是說，當(dāng)跟蹤緩沖區(qū)填滿時(shí)，它將刪除舊數(shù)據(jù)并用新數(shù)據(jù)替換它。由于在出現(xiàn)問題時(shí)只有最近的跟蹤信息是相關(guān)的，因此在應(yīng)用程序正常運(yùn)行期間無需停止和啟動(dòng)跟蹤。只有在檢測到問題時(shí)才需要禁用跟蹤器，以便跟蹤記錄導(dǎo)致錯(cuò)誤的歷史記錄。如果應(yīng)用程序中需要間隔跟蹤，它可以將 ASCII“1”寫入 trace_fd 以啟用跟蹤。

下面是一個(gè)名為simple_trace.c的簡單程序示例，它使用上述初始化過程：

req.tv_sec = 0;
req.tv_nsec = 1000;
write(marker_fd, "before nano\n", 12);
nanosleep(&req, NULL);
write(marker_fd, "after nano\n", 11);
write(trace_fd, "0", 1);

（由于這是一個(gè)僅用于示例目的的簡單程序，因此未添加錯(cuò)誤檢查。）這是跟蹤這個(gè)簡單程序的過程：

[tracing]# echo 0 > tracing_on
[tracing]# echo function_graph > current_tracer
[tracing]# ~/simple_trace
[tracing]# cat trace

第一行禁用跟蹤，因?yàn)槌绦驅(qū)⒃趩?dòng)時(shí)啟用它。接下來選擇函數(shù)圖跟蹤器。程序被執(zhí)行，結(jié)果如下。請注意，輸出可能有點(diǎn)冗長，其中大部分內(nèi)容已被刪除并替換為 [...]：

[...]
  0)               |      __kmalloc() {
  0)   0.528 us    |        get_slab();
  0)   2.271 us    |      }
  0)               |      /* before nano */
  0)               |      kfree() {
  0)   0.475 us    |        __phys_addr();
  0)   2.062 us    |      }
  0)   0.608 us    |      inotify_inode_queue_event();
  0)   0.485 us    |      __fsnotify_parent();
 [...]
  1)   0.523 us    |          _spin_unlock();
  0)   0.495 us    |    current_kernel_time();
  1)               |          it_real_fn() {
  0)   1.602 us    |  }
  1)   0.728 us    |            __rcu_read_lock();
  0)               |  sys_nanosleep() {
  0)               |    hrtimer_nanosleep() {
  0)   0.526 us    |      hrtimer_init();
  1)   0.418 us    |            __rcu_read_lock();
  0)               |      do_nanosleep() {
  1)   1.114 us    |            _spin_lock_irqsave();
 [...]
  0)               |      __kmalloc() {
  1)   2.760 us    |  }
  0)   0.556 us    |        get_slab();
  1)               |  mwait_idle() {
  0)   1.851 us    |      }
  0)               |      /* after nano */
  0)               |      kfree() {
  0)   0.486 us    |        __phys_addr();

請注意，對 trace_marker 的寫入在函數(shù)圖跟蹤器中顯示為注釋。這里的第一列代表 CPU。當(dāng)我們像這樣交錯(cuò) CPU 跟蹤時(shí)，可能很難讀取跟蹤。工具 grep 可以很容易地過濾它，或者可以使用 per_cpu 跟蹤文件。per_cpu 跟蹤文件位于 per_cpu 下的 debugfs 跟蹤目錄中。

1 2	[tracing]# ls per_cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7

在這些 CPU 目錄中的每一個(gè)目錄中都存在一個(gè)跟蹤文件，僅顯示該 CPU 的跟蹤。要在不受其他 CPU 干擾的情況下更好地了解函數(shù)圖跟蹤器，只需查看 per_cpu/cpu0/trace。

[tracing]# cat per_cpu/cpu0/trace
 0)               |      __kmalloc() {
 0)   0.528 us    |        get_slab();
 0)   2.271 us    |      }
 0)               |      /* before nano */
 0)               |      kfree() {
 0)   0.475 us    |        __phys_addr();
 0)   2.062 us    |      }
 0)   0.608 us    |      inotify_inode_queue_event();
 0)   0.485 us    |      __fsnotify_parent();
 0)   0.488 us    |      inotify_dentry_parent_queue_event();
 0)   1.106 us    |      fsnotify();
[...]
 0)   0.721 us    |    _spin_unlock_irqrestore();
 0)   3.380 us    |  }
 0)               |  audit_syscall_entry() {
 0)   0.495 us    |    current_kernel_time();
 0)   1.602 us    |  }
 0)               |  sys_nanosleep() {
 0)               |    hrtimer_nanosleep() {
 0)   0.526 us    |      hrtimer_init();
 0)               |      do_nanosleep() {
 0)               |        hrtimer_start_range_ns() {
 0)               |          __hrtimer_start_range_ns() {
 0)               |            lock_hrtimer_base() {
 0)   0.866 us    |              _spin_lock_irqsave();
[...]
 0)               |      __kmalloc() {
 0)               |        get_slab() {
 0)   1.851 us    |      }
 0)               |      /* after nano */
 0)               |      kfree() {
 0)   0.486 us    |        __phys_addr();

9. Disabling the Tracer Within the Kernel

在內(nèi)核驅(qū)動(dòng)程序的開發(fā)過程中，可能會(huì)存在測試過程中出現(xiàn)的奇怪錯(cuò)誤。也許驅(qū)動(dòng)陷入睡眠狀態(tài)，永遠(yuǎn)不會(huì)醒來。當(dāng)內(nèi)核事件發(fā)生時(shí)，試圖從用戶空間禁用跟蹤器是很困難的，通常會(huì)導(dǎo)致緩沖區(qū)溢出和相關(guān)信息丟失，然后用戶才能停止跟蹤。

有兩個(gè)在內(nèi)核中運(yùn)行良好的函數(shù)：tracing_on()和tracking_off()。這兩個(gè)行為就像分別將“1”或“0” echo 到tracing_on文件中一樣。如果內(nèi)核中存在可以檢查的某些條件，則可以通過添加如下內(nèi)容來停止跟蹤器：

1 2	if (test_for_error()) tracking_off();

接下來，添加幾個(gè)trace_printk() s（參見第 1 部分），重新編譯并引導(dǎo)內(nèi)核。然后，您可以啟用函數(shù)或函數(shù)圖跟蹤器，然后等待錯(cuò)誤條件發(fā)生。檢查tracing_on 文件將讓您知道錯(cuò)誤條件何時(shí)發(fā)生。當(dāng)內(nèi)核調(diào)用tracking_off()時(shí)，它將從“1”切換到“0” 。

檢查跟蹤后，或?qū)⑵浔４嬖诹硪粋€(gè)文件中：

1	cat trace > ~/trace.sav

您可以繼續(xù)跟蹤以檢查另一個(gè)命中。為此，只需將“1” echo 到tracing_on 中，跟蹤將繼續(xù)。如果可以合法觸發(fā)觸發(fā)tracing_off()調(diào)用的條件，這也很有用。如果條件是由正常操作觸發(fā)的，只需通過在tracing_on 中echo “1”來重新啟動(dòng)跟蹤，希望下次遇到條件時(shí)將是因?yàn)楫惓！?/p>

10. ftrace_dump_on_oops

有時(shí)內(nèi)核會(huì)崩潰，檢查內(nèi)存和崩潰狀態(tài)更像是一門 CSI 科學(xué)，而不是程序調(diào)試科學(xué)。將kdump / kexec與crash 實(shí)用程序一起使用是檢查崩潰點(diǎn)系統(tǒng)狀態(tài)的一種有價(jià)值的方法，但它不會(huì)讓您看到在導(dǎo)致崩潰的事件之前發(fā)生了什么。

在內(nèi)核引導(dǎo)參數(shù)中配置 Ftrace 并啟用ftrace_dump_on_oops，或者通過在/proc/sys/kernel/ftrace_dump_on_oops 中echo “1” ，將使 Ftrace 能夠在 oops 或 panic 時(shí)以 ASCII 格式將整個(gè)跟蹤緩沖區(qū)轉(zhuǎn)儲(chǔ)到控制臺(tái)。將控制臺(tái)輸出到串行日志使調(diào)試崩潰更容易。您現(xiàn)在可以追溯導(dǎo)致崩潰的事件。

轉(zhuǎn)儲(chǔ)到控制臺(tái)可能需要很長時(shí)間，因?yàn)槟J(rèn)的 Ftrace 環(huán)形緩沖區(qū)每個(gè) CPU 超過 1 兆字節(jié)。要縮小環(huán)形緩沖區(qū)的大小，請將希望環(huán)形緩沖區(qū)的千字節(jié)數(shù)寫入 buffer_size_kb。請注意，該值是每個(gè) CPU，而不是環(huán)形緩沖區(qū)的總大小。

1	[tracing]# echo 50 > buffer_size_kb

以上將把 Ftrace 環(huán)形緩沖區(qū)縮小到每個(gè) CPU 50 KB。您還可以使用sysrq-z將 Ftrace 緩沖區(qū)的轉(zhuǎn)儲(chǔ)觸發(fā)到控制臺(tái) 。

要為內(nèi)核轉(zhuǎn)儲(chǔ)選擇特定位置，內(nèi)核可以直接調(diào)用 ftrace_dump()。請注意，這可能會(huì)永久禁用 Ftrace，可能需要重新啟動(dòng)才能再次啟用它。這是因?yàn)?ftrace_dump()讀取緩沖區(qū)。緩沖區(qū)被寫入所有上下文（中斷、NMI、調(diào)度），但緩沖區(qū)的讀取需要鎖定。為了能夠執(zhí)行ftrace_dump()鎖定被禁用并且緩沖區(qū)可能最終在輸出后被破壞。

/*
 * The following code will lock up the box, so we dump out the
 * trace before we hit that location.
 */
ftrace_dump();

/* code that locks up */

11. Stack Tracing

最后要討論的主題是檢查內(nèi)核堆棧大小以及每個(gè)函數(shù)使用多少堆?？臻g的能力。啟用堆棧跟蹤器 ( CONFIG_STACK_TRACER ) 將顯示堆棧的最大使用發(fā)生在哪里。

堆棧跟蹤器是從函數(shù)跟蹤器基礎(chǔ)結(jié)構(gòu)構(gòu)建的。它不使用 Ftrace 環(huán)形緩沖區(qū)，但確實(shí)使用函數(shù)跟蹤器來掛鉤每個(gè)函數(shù)調(diào)用。因?yàn)樗褂煤瘮?shù)跟蹤器基礎(chǔ)結(jié)構(gòu)，所以在未啟用時(shí)不會(huì)增加開銷。要啟用堆棧跟蹤器，請將 1 echo 到 /proc/sys/kernel/stack_tracer_enabled 中。要查看啟動(dòng)期間的最大堆棧大小，請將“ stacktrace ”添加到內(nèi)核啟動(dòng)參數(shù)。

堆棧跟蹤器在每次函數(shù)調(diào)用時(shí)檢查堆棧的大小。如果它大于最后記錄的最大值，它會(huì)記錄堆棧跟蹤并使用新大小更新最大值。要查看當(dāng)前最大值，請查看 stack_max_size文件。

[tracing]# echo 1 > /proc/sys/kernel/stack_tracer_enabled
[tracing]# cat stack_max_size
2928
[tracing]# cat stack_trace
        Depth    Size   Location    (34 entries)
        -----    ----   --------
  0)     2952      16   mempool_alloc_slab+0x15/0x17
  1)     2936     144   mempool_alloc+0x52/0x104
  2)     2792      16   scsi_sg_alloc+0x4a/0x4c [scsi_mod]
  3)     2776     112   __sg_alloc_table+0x62/0x103
[...]
 13)     2072      48   __elv_add_request+0x98/0x9f
 14)     2024     112   __make_request+0x43e/0x4bb
 15)     1912     224   generic_make_request+0x424/0x471
 16)     1688      80   submit_bio+0x108/0x115
 17)     1608      48   submit_bh+0xfc/0x11e
 18)     1560     112   __block_write_full_page+0x1ee/0x2e8
 19)     1448      80   block_write_full_page_endio+0xff/0x10e
 20)     1368      16   block_write_full_page+0x15/0x17
 21)     1352      16   blkdev_writepage+0x18/0x1a
 22)     1336      32   __writepage+0x1a/0x40
 23)     1304     304   write_cache_pages+0x241/0x3c1
 24)     1000      16   generic_writepages+0x27/0x29
[...]
 30)      424      64   bdi_writeback_task+0x3f/0xb0
 31)      360      48   bdi_start_fn+0x76/0xd7
 32)      312     128   kthread+0x7f/0x87
 33)      184     184   child_rip+0xa/0x20

這不僅為您提供了找到的最大堆棧的大小，還顯示了每個(gè)函數(shù)使用的堆棧大小的細(xì)分。請注意， write_cache_pages的堆棧最大，使用了 304 個(gè)字節(jié)，其次是generic_make_request，使用了 224 個(gè)字節(jié)的堆棧。

要重置最大值，請將“0”回顯到stack_max_size 文件中。

1	[tracing]# echo 0 > stack_max_size

保持運(yùn)行一段時(shí)間將顯示內(nèi)核使用過多堆棧的位置。但請記住，堆棧跟蹤器只有在未啟用時(shí)才沒有開銷。當(dāng)它運(yùn)行時(shí)，您可能會(huì)注意到性能有所下降。

請注意，當(dāng)內(nèi)核使用單獨(dú)的堆棧時(shí)，堆棧跟蹤器不會(huì)跟蹤最大堆棧大小。因?yàn)橹袛嘤凶约旱亩褩?，它不?huì)跟蹤那里的堆棧使用情況。原因是當(dāng)堆棧不是當(dāng)前任務(wù)的堆棧時(shí)，目前沒有簡單的方法可以快速查看堆棧的頂部是什么。使用拆分堆棧時(shí)，進(jìn)程堆?？赡苁莾身?，而中斷堆?？赡苤挥幸豁摗＿@可能會(huì)在未來修復(fù)，但在使用堆棧跟蹤器時(shí)請記住這一點(diǎn)。

12. Function filtering

運(yùn)行函數(shù)跟蹤器可能會(huì)讓人不知所措。數(shù)據(jù)量可能很大，人腦很難掌握。Ftrace 提供了一種方法來限制您看到的功能。存在兩個(gè)文件，可讓您限制跟蹤的功能：

1 2	set_ftrace_filter set_ftrace_notrace

這些過濾功能取決于CONFIG_DYNAMIC_FTRACE 選項(xiàng)。如前幾篇文章所述，當(dāng)啟用此配置時(shí)，所有mcount調(diào)用者位置都將被存儲(chǔ)，并在啟動(dòng)時(shí)轉(zhuǎn)換為 NOP。這些位置被保存并用于在功能跟蹤器被激活時(shí)啟用跟蹤。但這也有一個(gè)很好的副作用：并非所有功能都必須啟用。上述文件將確定哪些功能被啟用，哪些不啟用。

當(dāng)set_ftrace_filter 中列出任何函數(shù)時(shí)，只會(huì)跟蹤那些函數(shù)。當(dāng)跟蹤處于活動(dòng)狀態(tài)時(shí)，這將有助于系統(tǒng)的性能。跟蹤每個(gè)函數(shù)會(huì)產(chǎn)生很大的開銷，但是在使用set_ftrace_filter 時(shí)，只有該文件中列出的那些函數(shù)才會(huì)更改 NOP 以調(diào)用跟蹤器。根據(jù)正在跟蹤的功能，僅啟用幾百個(gè)功能幾乎不會(huì)引起注意。

該set_ftrace_notrace文件是相反set_ftrace_filter。不是將跟蹤限制為一組函數(shù)，而是不會(huì)跟蹤set_ftrace_notrace 中列出的函數(shù)。某些函數(shù)經(jīng)常出現(xiàn)，跟蹤這些函數(shù)不僅會(huì)減慢系統(tǒng)速度，還會(huì)填滿跟蹤緩沖區(qū)，并使分析您關(guān)心的函數(shù)變得更加困難。rcu_read_lock()和spin_lock()等函數(shù) 屬于這一類。

向這些文件添加函數(shù)的過程通常使用 bash 重定向。使用符號“>”將刪除文件中的所有現(xiàn)有函數(shù)并將正在回顯的內(nèi)容添加到文件中。使用“>>”附加到文件將保留現(xiàn)有功能并添加新功能。

[tracing]# echo sys_read > set_ftrace_filter
[tracing]# cat set_ftrace_filter
sys_read
[tracing]# echo sys_write >> set_ftrace_filter
[tracing]# cat set_ftrace_filter
sys_write
sys_read
[tracing]# echo sys_open > set_ftrace_filter
[tracing]# cat set_ftrace_filter
sys_open

要?jiǎng)h除所有功能，只需在過濾器文件中回顯一個(gè)空行即可。

[tracing]# echo sys_read sys_open sys_write > set_ftrace_notrace 
[tracing]# cat set_ftrace_notrace
sys_open
sys_write
sys_read
[tracing]# echo > set_ftrace_notrace
[tracing]# cat set_ftrace_notrace
[tracing]#

這些文件中列出的函數(shù)也可以在內(nèi)核命令行上設(shè)置。選項(xiàng) ftrace_notrace 和 ftrace_filter 將通過列出逗號分隔的函數(shù)集來預(yù)設(shè)這些文件。

ftrace_notrace=rcu_read_lock,rcu_read_unlock,spin_lock,spin_unlock
ftrace_filter=kfree,kmalloc,schedule,vmalloc_fault,spurious_fault

內(nèi)核命令行添加的函數(shù)設(shè)置了相應(yīng)過濾器文件中的內(nèi)容。這些選項(xiàng)僅預(yù)加載文件，仍然可以使用如上所述的 bash 重定向來刪除或添加功能。set_ftrace_notrace 中列出的函數(shù)優(yōu)先。也就是說，如果一個(gè)函數(shù)同時(shí)列在 set_ftrace_notrace 和 set_ftrace_filter 中，則不會(huì)跟蹤該函數(shù)。

13. Wildcard filters

可以添加到過濾器文件的函數(shù)列表顯示在 available_filter_functions 文件中。這個(gè)函數(shù)列表源自前面提到的存儲(chǔ)的 mcount 調(diào)用者列表。

[tracing]# cat available_filter_functions | head -8
_stext
do_one_initcall
run_init_process
init_post
name_to_dev_t
create_dev
T.627
set_personality_64bit

您可以 grep 此文件并將結(jié)果重定向到過濾器文件之一：

[tracing]# grep sched available_filter_functions > set_ftrace_filter
[tracing]# cat set_ftrace_filter | head -8
save_stack_address_nosched
mce_schedule_work
smp_reschedule_interrupt
native_smp_send_reschedule
sys32_sched_rr_get_interval
sched_avg_update
proc_sched_set_task
sys_sched_get_priority_max

不幸的是，向過濾文件添加大量函數(shù)很慢，您會(huì)注意到上面的 grep 需要幾秒鐘才能執(zhí)行。這是因?yàn)閷懭脒^濾器文件的每個(gè)函數(shù)名稱將被單獨(dú)處理。上面的 grep 產(chǎn)生了 300 多個(gè)函數(shù)名。這 300 個(gè)名稱中的每一個(gè)都將與內(nèi)核中的每個(gè)函數(shù)名稱進(jìn)行比較（使用 strcmp()），這相當(dāng)多。

1 2	[tracing]# wc -l available_filter_functions 24331 available_filter_functions

所以上面的 grep 導(dǎo)致set_ftrace_filter生成超過 300 * 24331 (7,299,300) 次比較！

幸運(yùn)的是，這些文件也使用通配符；以下 glob 表達(dá)式是有效的：

value* - 選擇所有以value開頭的函數(shù)。*value* - 選擇所有包含文本value 的函數(shù)。*value - 選擇所有以value結(jié)尾的函數(shù)。

內(nèi)核包含一個(gè)相當(dāng)簡單的解析器，不會(huì)以預(yù)期的方式處理 value*value。它將忽略第二個(gè) 值并選擇所有以value開頭的函數(shù)，而不管它以什么結(jié)尾。傳遞給過濾器文件的通配符直接針對每個(gè)可用函數(shù)進(jìn)行處理，這比在列表中傳遞單個(gè)函數(shù)要快得多。

因?yàn)?bash 也使用星號 (*)，所以最好用引號將輸入括起來：

[tracing]# echo set* > set_ftrace_filter
[tracing]# cat set_ftrace_filter
#### all functions enabled ####
[tracing]# echo 'set*' > set_ftrace_filter
[tracing]# cat set_ftrace_filter | head -5
set_personality_64bit
set_intr_gate_ist
set_intr_gate
set_intr_gate
set_tsc_mode

過濾器還可以通過在過濾器文件的輸入中使用“mod”命令來僅選擇屬于特定模塊的那些函數(shù)：

[tracing]# echo ':mod:tg3' > set_ftrace_filter
[tracing]# cat set_ftrace_filter |head -8
tg3_write32
tg3_read32
tg3_write_flush_reg32
tw32_mailbox_flush
tg3_write32_tx_mbox
tg3_read32_mbox_5906
tg3_write32_mbox_5906
tg3_disable_ints

如果您正在調(diào)試單個(gè)模塊，并且只想在跟蹤中查看屬于該模塊的函數(shù)，這將非常有用。

在之前的文章中，啟用和禁用記錄到環(huán)形緩沖區(qū)是使用tracing_on文件以及tracing_on()和 tracing_off()內(nèi)核函數(shù)完成的。但是，如果您不想重新編譯內(nèi)核，并且想在特定函數(shù)處停止跟蹤，則 set_ftrace_filter有一個(gè)方法可以這樣做。使功能跟蹤啟用或禁用環(huán)形緩沖區(qū)的命令格式如下：

function:command[:count]

這將在函數(shù)開始時(shí)執(zhí)行命令。該命令是 traceon或traceoff，并且可以添加一個(gè)可選的計(jì)數(shù)以使命令只執(zhí)行給定的次數(shù)。如果計(jì)數(shù)被保留（包括前導(dǎo)冒號），則每次調(diào)用該函數(shù)時(shí)都會(huì)執(zhí)行該命令。

不久前，我正在調(diào)試對內(nèi)核所做的更改，該更改導(dǎo)致某些程序出現(xiàn)分段錯(cuò)誤。我很難捕捉到跟蹤，因?yàn)楫?dāng)我看到分段錯(cuò)誤后能夠停止跟蹤時(shí)，數(shù)據(jù)已經(jīng)被覆蓋了。但是控制臺(tái)上的回溯顯示正在調(diào)用函數(shù)__bad_area_nosemaphore。然后我可以使用以下命令停止跟蹤器：

[tracing]# echo '__bad_area_nosemaphore:traceoff' > set_ftrace_filter
[tracing]# cat set_ftrace_filter
#### all functions enabled ####
__bad_area_nosemaphore:traceoff:unlimited
[tracing]# echo function > current_tracer

請注意，帶有命令的函數(shù)不會(huì)影響一般過濾器。即使已將命令添加到 __bad_area_nosemaphore，過濾器仍允許跟蹤所有函數(shù)。命令和過濾器功能是分開的，互不影響。將上述命令附加到函數(shù) __bad_area_nosemaphore 后，下次發(fā)生分段錯(cuò)誤時(shí)，跟蹤停止并包含調(diào)試情況所需的數(shù)據(jù)。

14. Removing functions from the filters

如前所述，用“>”回顯將清除過濾器文件。但是如果您只想從過濾器中刪除一些功能怎么辦？

1 2	[tracing]# cat set_ftrace_filter > /tmp/filter [tracing]# grep -v lock /tmp/filter > set_ftrace_filter

上述工作，但如前所述，如果 set_ftrace_filter 中已有多個(gè)函數(shù)，則可能需要一段時(shí)間才能完成。以下執(zhí)行相同的操作，但速度要快得多：

1	[tracing]# echo '!lock' >> set_ftrace_filter

這 '！'符號將刪除過濾器文件中列出的函數(shù)。如上所示，“！”與通配符一起使用，但也可以與單個(gè)函數(shù)一起使用。自從 '！'在 bash 中具有特殊含義，它必須用單引號括起來，否則 bash 將嘗試執(zhí)行其后的內(nèi)容。另請注意使用了“>>”。如果您錯(cuò)誤地使用了“>”，則過濾器文件中將沒有任何功能。因?yàn)槊詈瓦^濾器不會(huì)相互干擾，清除 set_ftrace_filter 不會(huì)清除命令。命令必須用“！”清除象征。

[tracing]# echo 'sched*' > set_ftrace_filter
[tracing]# echo 'schedule:traceoff' >> set_ftrace_filter
[tracing]# cat trace | tail -5
schedule_console_callback
schedule_bh
schedule_iso_resource
schedule_reallocations
schedule:traceoff:unlimited
[tracing]# echo > set_ftrace_filter
[tracing]# cat set_ftrace_filter
#### all functions enabled ####
schedule:traceoff:unlimited
[tracing]# echo '!schedule:traceoff' >> set_ftrace_filter
[tracing]# cat set_ftrace_filter
#### all functions enabled ####
[tracing]#

這可能看起來很別扭，但是使用“>”和“>>”只影響要跟蹤的函數(shù)而不影響函數(shù)命令，實(shí)際上簡化了過濾函數(shù)和添加和刪除命令之間的控制。

15. Tracing a specific process

也許您只需要跟蹤一個(gè)特定的進(jìn)程或一組進(jìn)程。文件 set_ftrace_pid 允許您指定要跟蹤的特定進(jìn)程。要僅跟蹤當(dāng)前線程，您可以執(zhí)行以下操作：

1	[tracing]# echo $$ > set_ftrace_pid

上面將設(shè)置函數(shù) tracer 只跟蹤執(zhí)行 echo 命令的 bash shell。如果要跟蹤特定進(jìn)程，可以創(chuàng)建一個(gè) shell 腳本包裝程序。

[tracing]# cat ~/bin/ftrace-me
#!/bin/sh
DEBUGFS=`grep debugfs /proc/mounts | awk '{ print $2; }'`
echo $$ > $DEBUGFS/tracing/set_ftrace_pid
echo function > $DEBUGFS/tracing/current_tracer
exec $*
[tracing]# ~/bin/ftrace-me ls -ltr

請注意，如果要在執(zhí)行上述操作后返回通用函數(shù)跟蹤，則必須清除 set_ftrace_pid 文件。

1	[tracing]# echo -1 > set_ftrace_pid

16. What calls a specific function?

有時(shí)了解什么在調(diào)用特定函數(shù)很有用。直接前任很有幫助，但整個(gè)回溯甚至更好。函數(shù)跟蹤器包含一個(gè)選項(xiàng)，該選項(xiàng)將為跟蹤器調(diào)用的每個(gè)函數(shù)在環(huán)形緩沖區(qū)中創(chuàng)建一個(gè)回溯。由于為每個(gè)函數(shù)創(chuàng)建回溯具有很大的開銷，這可能會(huì)實(shí)時(shí)鎖定系統(tǒng)，因此在使用此功能時(shí)必須小心。想象一下運(yùn)行在 1000 HZ 的較慢系統(tǒng)上的定時(shí)器中斷。很可能讓定時(shí)器中斷調(diào)用產(chǎn)生回溯的每個(gè)函數(shù)需要 1 毫秒才能完成。到定時(shí)器中斷返回時(shí)，將在任何其他工作完成之前觸發(fā)一個(gè)新的中斷，從而導(dǎo)致活鎖。

要使用函數(shù)跟蹤器回溯功能，被調(diào)用的函數(shù)必須受到函數(shù)過濾器的限制。啟用函數(shù)回溯的選項(xiàng)是函數(shù)跟蹤器獨(dú)有的，只有在啟用函數(shù)跟蹤器時(shí)才能激活它。這意味著您必須先啟用函數(shù)跟蹤器，然后才能訪問該選項(xiàng)：

[tracing]# echo kfree > set_ftrace_filter
[tracing]# cat set_ftrace_filter
kfree
[tracing]# echo function > current_tracer
[tracing]# echo 1 > options/func_stack_trace
[tracing]# cat trace | tail -8
 => sys32_execve
 => ia32_ptregs_common
             cat-6829  [000] 1867248.965100: kfree <-free_bprm
             cat-6829  [000] 1867248.965100: <stack trace>

 => free_bprm
 => compat_do_execve
 => sys32_execve
 => ia32_ptregs_common
[tracing]# echo 0 > options/func_stack_trace
[tracing]# echo > set_ftrace_filter

請注意，在啟用 func_stack_trace 選項(xiàng)以確保啟用過濾器之前，我小心地對 set_ftrace_filter 進(jìn)行分類。最后，我在禁用過濾器之前禁用了 options/func_stack_trace。還要注意該選項(xiàng)是非易失性的，也就是說，即使您在 current_tracer 中啟用了另一個(gè)跟蹤器插件，如果您重新啟用跟蹤器功能，該選項(xiàng)仍然會(huì)啟用。

17. The function_graph tracer

函數(shù)跟蹤器非常強(qiáng)大，但可能很難理解它產(chǎn)生的線性格式。Frederic Weisbecker 已將函數(shù)跟蹤器擴(kuò)展到 function_graph 跟蹤器。function_graph 跟蹤器搭載了大部分由函數(shù)跟蹤器創(chuàng)建的代碼，但在mcount調(diào)用中添加了自己的鉤子。因?yàn)樗匀皇褂胢count調(diào)用方法，所以上面解釋的大部分函數(shù)過濾也適用于 function_graph 跟蹤器，但traceon / traceoff命令和set_ftrace_pid 除外（盡管后者將來可能會(huì)改變）。function_graph tracer在之前的文章中也有說明，但是set_graph_function文件沒有說明。上一節(jié)中使用的func_stack_trace可以看到什么可能調(diào)用一個(gè)函數(shù)，但是set_graph_function可以用來查看一個(gè)函數(shù)調(diào)用了什么：

[tracing]# echo kfree > set_graph_function
[tracing]# echo function_graph > current_tracer
[tracing]# cat trace
# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)               |  kfree() {
 0)               |    virt_to_cache() {
 0)               |      virt_to_head_page() {
 0)   0.955 us    |        __phys_addr();
 0)   2.643 us    |      }
 0)   4.299 us    |    }
 0)   0.855 us    |    __cache_free();
 0)   ==========> |
 0)               |    smp_apic_timer_interrupt() {
 0)               |      apic_write() {
 0)   0.849 us    |        native_apic_mem_write();
 0)   2.853 us    |      }
[tracing]# echo > set_graph_function

這將顯示僅由kfree()執(zhí)行的調(diào)用圖?！?==========> ”表示通話過程中發(fā)生了中斷。跟蹤記錄kfree() 塊中的所有函數(shù)，甚至是那些在kfree()范圍內(nèi)觸發(fā)的中斷調(diào)用的函數(shù)。

function_graph 跟蹤器顯示函數(shù)在持續(xù)時(shí)間字段中花費(fèi)的時(shí)間。在之前的文章中提到，只有葉子函數(shù)，即不調(diào)用其他函數(shù)的葉函數(shù)，才有準(zhǔn)確的持續(xù)時(shí)間，因?yàn)楦负瘮?shù)的持續(xù)時(shí)間還包括 function_graph 跟蹤器調(diào)用子函數(shù)的開銷。通過使用set_ftrace_filter文件，您可以強(qiáng)制任何函數(shù)成為 function_graph 跟蹤器中的葉函數(shù)，這將允許您查看該函數(shù)的準(zhǔn)確持續(xù)時(shí)間。

[tracing]# echo smp_apic_timer_interrupt > set_ftrace_filter
[tracing]# echo function_graph > current_tracer
[tracing]# cat trace | head
# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 1)   ==========> |
 1) + 16.433 us   |  smp_apic_timer_interrupt();
 1)   ==========> |
 1) + 25.897 us   |  smp_apic_timer_interrupt();
 1)   ==========> |
 1) + 24.764 us   |  smp_apic_timer_interrupt();

上面顯示定時(shí)器中斷需要 16 到 26 微秒才能完成。

18. Function profiling

oprofile和perf是非常強(qiáng)大的分析工具，它們定期對系統(tǒng)進(jìn)行采樣，并可以顯示大部分時(shí)間都花在了什么地方。使用函數(shù)分析器，可以很好地查看實(shí)際的函數(shù)執(zhí)行情況，而不僅僅是示例。如果內(nèi)核中配置了CONFIG_FUNCTION_GRAPH_TRACER，則函數(shù)分析器將使用函數(shù)圖基礎(chǔ)結(jié)構(gòu)來記錄函數(shù)執(zhí)行了多長時(shí)間。如果只配置了CONFIG_FUNCTION_TRACER，函數(shù)分析器將只計(jì)算被調(diào)用的函數(shù)。

[tracing]# echo nop > current_tracer
[tracing]# echo 1 > function_profile_enabled
[tracing]# cat trace_stat/function 0 |head
  Function                               Hit    Time            Avg
  --------                               ---    ----            ---
  schedule                             22943    1994458706 us     86931.03 us 
  poll_schedule_timeout                 8683    1429165515 us     164593.5 us 
  schedule_hrtimeout_range              8638    1429155793 us     165449.8 us 
  sys_poll                             12366    875206110 us     70775.19 us 
  do_sys_poll                          12367    875136511 us     70763.84 us 
  compat_sys_select                     3395    527531945 us     155384.9 us 
  compat_core_sys_select                3395    527503300 us     155376.5 us 
  do_select                             3395    527477553 us     155368.9 us

以上還包括函數(shù)被搶占或 schedule() 被調(diào)用以及任務(wù)被換出的次數(shù)。這可能看起來沒用，但它確實(shí)可以讓我們了解哪些函數(shù)經(jīng)常被搶占。Ftrace 還包括允許您讓函數(shù)圖跟蹤器忽略任務(wù)計(jì)劃時(shí)間的選項(xiàng)。

[tracing]# echo 0 > options/sleep-time
[tracing]# echo 0 > function_profile_enabled
[tracing]# echo 1 > function_profile_enabled
[tracing]# cat trace_stat/function0  | head
  Function                               Hit    Time            Avg
  --------                               ---    ----            ---
  default_idle                          2493    6763414 us     2712.962 us 
  native_safe_halt                      2492    6760641 us     2712.938 us 
  sys_poll                              4723    714243.6 us     151.226 us  
  do_sys_poll                           4723    692887.4 us     146.704 us  
  sys_read                              9211    460896.3 us     50.037 us   
  vfs_read                              9243    434521.2 us     47.010 us   
  smp_apic_timer_interrupt              3940    275747.4 us     69.986 us   
  sock_poll                            80613    268743.2 us     3.333 us

請注意，sleep-time選項(xiàng)包含“-”，而不是 sleep_time。

禁用功能分析器然后重新啟用它會(huì)導(dǎo)致數(shù)字重置。該列表按平均時(shí)間排序，但使用腳本您可以輕松地按任何數(shù)字排序。所述trace_stat / function0僅表示存在一個(gè)CPU 0 trace_stat /功能＃為系統(tǒng)上的每個(gè)CPU。所有被追蹤和命中的函數(shù)都在這個(gè)文件中。

1 2	[tracing]# cat trace_stat/function0 \| wc -l 2978

未命中的函數(shù)未列出。以上顯示自我開始分析以來，已命中 2978 個(gè)函數(shù)。

影響分析的另一個(gè)選項(xiàng)是圖形時(shí)間（再次使用“-”）。默認(rèn)情況下它是啟用的。啟用后，函數(shù)的時(shí)間包括函數(shù)內(nèi)調(diào)用的所有函數(shù)的時(shí)間。從上面示例的輸出中可以看出，列出了幾個(gè)系統(tǒng)調(diào)用的平均值最高。禁用時(shí)，次數(shù)只包括函數(shù)本身的執(zhí)行次數(shù)，不包括從函數(shù)調(diào)用函數(shù)的次數(shù)：

[tracing]# echo 0 > options/graph-time
[tracing]# echo 0 > function_profile_enabled
[tracing]# echo 1 > function_profile_enabled
[tracing]# cat trace_stat/function0  | head
  Function                               Hit    Time            Avg
  --------                               ---    ----            ---
  mwait_idle                           10132    246835458 us     24361.96 us 
  tg_shares_up                        154467    389883.5 us     2.524 us    
  _raw_spin_lock_irqsave              343012    263504.3 us     0.768 us    
  _raw_spin_unlock_irqrestore         351269    175205.6 us     0.498 us    
  walk_tg_tree                         14087    126078.4 us     8.949 us    
  __set_se_shares                     274937    88436.65 us     0.321 us    
  _raw_spin_lock                      100715    82692.61 us     0.821 us    
  kstat_irqs_cpu                      257500    80124.96 us     0.311 us

請注意，睡眠時(shí)間和圖形時(shí)間也會(huì)影響 function_graph 跟蹤器顯示的持續(xù)時(shí)間。

19. 總結(jié)

函數(shù)跟蹤器非常強(qiáng)大，有很多不同的選項(xiàng)。它已經(jīng)在主線 Linux 中可用，并且希望在大多數(shù)發(fā)行版中默認(rèn)啟用。它允許您深入了解內(nèi)核及其功能庫，讓您很好地了解事情發(fā)生的原因。開始使用函數(shù)跟蹤器打開我們稱之為內(nèi)核的黑匣子。玩得開心！

原文：
https://carlyleliu.github.io/2021/Linux%E5%86%85%E6%A0%B8%E8%B0%83%E8%AF%95%EF%BC%88%E4%B8%80%EF%BC%89ftrace/

內(nèi)核調(diào)試?yán)鳎黤trace 使用教程