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（内核调试工具）》