Linux 內核調試工具ftrace 之（NOP動態插樁的實現原理）

ftrace 是 Linux 內核中的一種跟蹤工具，主要用于性能分析、調試和內核代碼的執行跟蹤。它通過在內核代碼的關鍵點插入探針（probe）來記錄函數調用和執行信息。這對于開發者排查問題、優化性能或者理解內核行為非常有用。

linux中主要支持兩種ftrace的實現方式：

1. _mcount機制，（主要在內核為5.10前版本），可見文章《ftrace之_mcount的實現原理》
2. 雙NOP指令動態插樁機制（主要在內核為5.10及以后版本）

下面將深入介紹雙NOP指令動態插樁機制的實現原理：

雙NOP指令動態插樁機制的實現

 * Due to -fpatchable-function-entry=2, the compiler has placed two NOPs before* the regular function prologue. For an enabled callsite, ftrace_init_nop() and* ftrace_make_call() have patched those NOPs to:** 	MOV	X9, LR* 	BL	<entry>** ... where <entry> is either ftrace_caller or ftrace_regs_caller.

• gcc編譯內核時加上 -fpatchable-function-entry=2 選項將會在每個支持被插樁的函數最前面插入兩條NOP指令。
• nop本身就是動態插樁機制，當需要追蹤該函數時，才會將該函數前面的nop指令替換為MOV X9, LR和BL <entry>（<entry>是ftrace_caller或ftrace_regs_caller）。

NOP入口的分析

1. 下面是實際的編譯的驅動函數匯編代碼：

0000000000000000 <gps_pcie_tty_close>:0:   d503201f        nop4:   d503201f        nop8:   d503233f        paciaspc:   a9bf7bfd        stp     x29, x30, [sp, #-16]!10:   aa0103e2        mov     x2, x114:   910003fd        mov     x29, sp18:   aa0003e1        mov     x1, x01c:   f941d000        ldr     x0, [x0, #928]20:   94000000        bl      0 <tty_port_close>24:   a8c17bfd        ldp     x29, x30, [sp], #1628:   d50323bf        autiasp2c:   d65f03c0        ret

2. 當該函數需要被追蹤，則將nop換成MOV X9, LR和BL ftrace_caller（這里以ftrace_caller為例）。

 * Each instrumented function follows the AAPCS, so here x0-x8 and x18-x30 are
live (x18 holds the Shadow Call Stack pointer), and x9-x17 are safe to clobber.

• 每個支持被追蹤的函數應該遵守AAPCS規定。根據 AAPCS 的規定，寄存器可分為調用者保存和被調用者保存兩類。調用者保存的寄存器需要在調用函數前由調用者保存其值，而被調用者保存的寄存器則由被調用的函數負責保存和恢復。寄存器 x0 至 x8 以及 x18 至 x30 被視為活躍寄存器（其中 x18 保存影子調用棧指針），而寄存器 x9 至 x17 則可安全地被覆蓋。
• 因此x9寄存器是可以直接用的，所以可以用來存調用者的返回地址即將LR_A存入到x9（可以發現這里和_mcount的處理方式不同，不用再先保存寄存器了）。
• 接下來就進入ftrace_caller或ftrace_regs_caller中
  此時棧分配如下圖：
  

3. ftrace_caller或ftrace_regs_caller中的任務

YM_CODE_START(ftrace_regs_caller)
#ifdef BTI_CBTI_C
#endifftrace_regs_entry	1b	ftrace_common
SYM_CODE_END(ftrace_regs_caller)SYM_CODE_START(ftrace_caller)
#ifdef BTI_CBTI_C
#endifftrace_regs_entry	0b	ftrace_common
SYM_CODE_END(ftrace_caller)

ftrace_caller或ftrace_regs_caller都會跳轉至ftrace_regs_entry，然后全部跳轉至b ftrace_common（b跳轉指令不會將返回地址存到lr寄存器中）。接下來分析一下ftrace_regs_entry與ftrace_common。

4. ftrace_regs_entry

    .macro  ftrace_regs_entry, allregs=0/* Make room for pt_regs, plus a callee frame */sub	sp, sp, #(S_FRAME_SIZE + 16)/* Save function arguments (and x9 for simplicity) */stp	x0, x1, [sp, #S_X0]stp	x2, x3, [sp, #S_X2]stp	x4, x5, [sp, #S_X4]stp	x6, x7, [sp, #S_X6]stp	x8, x9, [sp, #S_X8]/* Optionally save the callee-saved registers, always save the FP */.if \allregs == 1//這里是allregs == 1時額外要保存的現場stp	x10, x11, [sp, #S_X10]stp	x12, x13, [sp, #S_X12]stp	x14, x15, [sp, #S_X14]stp	x16, x17, [sp, #S_X16]stp	x18, x19, [sp, #S_X18]stp	x20, x21, [sp, #S_X20]stp	x22, x23, [sp, #S_X22]stp	x24, x25, [sp, #S_X24]stp	x26, x27, [sp, #S_X26]stp	x28, x29, [sp, #S_X28].else//這里是allregs == 0時額外要保存的現場str	x29, [sp, #S_FP].endif/* Save the callsite's SP and LR */add	x10, sp, #(S_FRAME_SIZE + 16)stp	x9, x10, [sp, #S_LR]/* Save the PC after the ftrace callsite */str	x30, [sp, #S_PC]/* Create a frame record for the callsite above pt_regs */stp	x29, x9, [sp, #S_FRAME_SIZE]add	x29, sp, #S_FRAME_SIZE/* Create our frame record within pt_regs. */stp	x29, x30, [sp, #S_STACKFRAME]add	x29, sp, #S_STACKFRAME.endm

• 在上面的現場保存后函數棧的分布如下圖：

5. 跳轉到ftrace_common

SYM_CODE_START(ftrace_common)sub	x0, x30, #AARCH64_INSN_SIZE	// ip (callsite's BL insn)mov	x1, x9				// parent_ip (callsite's LR)ldr_l	x2, function_trace_op		// opmov	x3, sp				// regsSYM_INNER_LABEL(ftrace_call, SYM_L_GLOBAL)bl	ftrace_stub#ifdef CONFIG_FUNCTION_GRAPH_TRACER
SYM_INNER_LABEL(ftrace_graph_call, SYM_L_GLOBAL) // ftrace_graph_caller();nop				// If enabled, this will be replaced// "b ftrace_graph_caller"
#endif/** At the callsite x0-x8 and x19-x30 were live. Any C code will have preserved* x19-x29 per the AAPCS, and we created frame records upon entry, so we need* to restore x0-x8, x29, and x30.*/
ftrace_common_return:/* Restore function arguments */ldp	x0, x1, [sp]ldp	x2, x3, [sp, #S_X2]ldp	x4, x5, [sp, #S_X4]ldp	x6, x7, [sp, #S_X6]ldr	x8, [sp, #S_X8]/* Restore the callsite's FP, LR, PC */ldr	x29, [sp, #S_FP]ldr	x30, [sp, #S_LR]ldr	x9, [sp, #S_PC]/* Restore the callsite's SP */add	sp, sp, #S_FRAME_SIZE + 16ret	x9
SYM_CODE_END(ftrace_common)

• ftrace_common分為兩段：跳轉到對應的trace回調函數前、從跳轉的trace回調函數返回后。

1. 跳轉到對應的trace回調函數前：

sub	x0, x30, #AARCH64_INSN_SIZE	// ip (callsite's BL insn)
mov	x1, x9				// parent_ip (callsite's LR)
ldr_l	x2, function_trace_op		// op
mov	x3, sp				// regs

主要是準備好給trace回調函數的參數。
參數類型大致為下面

(unsigned long ip, unsigned long parent_ip, struct ftrace_ops *op, struct pt_regs *regs)

2. 后面就是進入trace的回調函數中：
   • 將傳入的信息保存到trace的緩沖區中（棧幀結構體中struct pt_regs）。
   • 恢復追蹤函數B的現場，x0～x8，x19～x30。（B的環境這樣就沒有被破壞）
   • BL 到 函數B繼續執行（此時x30lr寄存器值為trace回調函數地址）。
   • 保存x0到對應的棧幀結構體中struct pt_regs的x0成員變量（函數返回值）。
   • 返回到ftrace_common的ftrace_common_return繼續執行。

3.ftrace_common_return：
* 這里的任務是恢復現場（通過保存的棧幀結構體struct pt_regs）。
* 通過ret指令直接跳轉到函數A。

4. 說明：
   • 為什么要組織FP_N、FP_B的幀記錄（即存放上一個函數的FP、LR），目的就是給具體的trace回調函數函數調用的信息，使trace回調函數能夠遞歸函數調用關系。
   • 在用棧進行參數傳遞時，被調用者都是用調用者的FP指針進行訪問的。

雙nop的跳轉流程

雙nop的跳轉流程和_mcount差不多，差別就是棧的設置以及保存，恢復，以及進入bl ftrace的時機不同。

具體的ftrace操作

見文章《Linux-ftrace（內核調試工具）》