Linux-ftrace-双nop机制的实现

Linux 内核调试工具ftrace 之（NOP动态插桩的实现原理）

ftrace 是 Linux 内核中的一种跟踪工具，主要用于性能分析、调试和内核代码的执行跟踪。它通过在内核代码的关键点插入探针（probe）来记录函数调用和执行信息。这对于开发者排查问题、优化性能或者理解内核行为非常有用。

linux中主要支持两种ftrace的实现方式：

_mcount机制，（主要在内核为5.10前版本），可见文章《ftrace之_mcount的实现原理》
双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        nop
   4:   d503201f        nop
   8:   d503233f        paciasp
   c:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
  10:   aa0103e2        mov     x2, x1
  14:   910003fd        mov     x29, sp
  18:   aa0003e1        mov     x1, x0
  1c:   f941d000        ldr     x0, [x0, #928]
  20:   94000000        bl      0 <tty_port_close>
  24:   a8c17bfd        ldp     x29, x30, [sp], #16
  28:   d50323bf        autiasp
  2c:   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_C
	BTI_C
#endif
	ftrace_regs_entry	1
	b	ftrace_common
SYM_CODE_END(ftrace_regs_caller)

SYM_CODE_START(ftrace_caller)
#ifdef BTI_C
	BTI_C
#endif
	ftrace_regs_entry	0
	b	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		// op
	mov	x3, sp				// regs

SYM_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 + 16

	ret	x9
SYM_CODE_END(ftrace_common)

ftrace_common分为两段：跳转到对应的trace回调函数前、从跳转的trace回调函数返回后。

跳转到对应的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)

后面就是进入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。

说明：
- 为什么要组织FP_N、FP_B的帧记录（即存放上一个函数的FP、LR），目的就是给具体的trace回调函数函数调用的信息，使trace回调函数能够递归函数调用关系。
- 在用栈进行参数传递时，被调用者都是用调用者的FP指针进行访问的。

双`nop`的跳转流程

双nop的跳转流程和_mcount差不多，差别就是栈的设置以及保存，恢复，以及进入bl ftrace的时机不同。

具体的ftrace操作

见文章《Linux-ftrace（内核调试工具）》

Linux-ftrace-双nop机制的实现

Linux 内核调试工具ftrace 之（NOP动态插桩的实现原理）

双NOP指令动态插桩机制的实现

NOP入口的分析

1. 下面是实际的编译的驱动函数汇编代码：

2. 当该函数需要被追踪，则将nop换成MOV X9, LR和BL ftrace_caller（这里以ftrace_caller为例）。

3. ftrace_caller或ftrace_regs_caller中的任务

4. ftrace_regs_entry

5. 跳转到ftrace_common

双nop的跳转流程

具体的ftrace操作

双`NOP`指令动态插桩机制的实现

`NOP`入口的分析

2. 当该函数需要被追踪，则将`nop`换成`MOV X9, LR`和`BL ftrace_caller`（这里以`ftrace_caller`为例）。

3. `ftrace_caller`或`ftrace_regs_caller`中的任务

4. `ftrace_regs_entry`

5. 跳转到`ftrace_common`

双`nop`的跳转流程