当前位置：首页 > wzjs >正文

福州建设招聘信息网站重庆旗帜制作

wzjs 2025/9/14 16:09:34

福州建设招聘信息网站,重庆旗帜制作,如何制作app演示视频,建设网站公司排名Linux 内核调试工具ftrace 之（_mcount的实现原理） ftrace 是 Linux 内核中的一种跟踪工具，主要用于性能分析、调试和内核代码的执行跟踪。它通过在内核代码的关键点插入探针（probe）来记录函数调用和执行信息。这对于开…

Linux 内核调试工具ftrace 之（_mcount的实现原理）

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

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

_mcount机制，（主要在内核为5.10前版本）
双NOP指令动态插桩机制（主要在内核为5.10及以后版本），见文章《ftrace之双nop机制实现原理》

下面将分别深入介绍两种机制的实现原理：

一、`_mcount`机制的实现

 * Gcc with -pg will put the following code in the beginning of each function:*      mov x0, x30*      bl _mcount*	[function's body ...]* "bl _mcount" may be replaced to "bl ftrace_caller" or NOP if dynamic* ftrace is enabled.

gcc编译内核时加上 -pg 选项将会在每个支持被插桩的函数前面插入mov x0, x30与bl _mcount指令。
如果开启了动态插桩，那bl _mcount会被bl ftrace_caller 或 NOP指令替换，当需要对该函数进行追踪时，将重新插入bl _mcount，取消追踪时会重新替换为bl ftrace_caller 或 NOP指令。这样会降低ftrace对性能的损耗。

`_mcount`入口的分析

下面是实际的编译的驱动函数汇编代码：
_mcount被插桩在函数的b74地址处（同样mov x0, x30也被插桩）。

0000000000000b58 <pcie_adc_ioctl>:b58:       a9bd7bfd        stp     x29, x30, [sp, #-48]!b5c:       910003fd        mov     x29, spb60:       a90153f3        stp     x19, x20, [sp, #16]b64:       d50320ff        xpaclrib68:       2a0103f4        mov     w20, w1b6c:       aa1e03e0        mov     x0, x30b70:       aa0203f3        mov     x19, x2b74:       94000000        bl      0 <_mcount>b78:       90000000        adrp    x0, 0 <__stack_chk_guard>b7c:       f9400001        ldr     x1, [x0]b80:       f90017e1        str     x1, [sp, #40]

插桩的两条指令并不是插入在函数的最前面第一、二地址处，而是在该函数将该函数的栈分配好以及保存好现场后再进行插桩。

下述的三点是编译器默认的规定（x0-x8 and x18-x30 are live (x18 holds the Shadow Call Stack pointer), and x9-x17 are safe to clobber.）即：
- 将父函数的FP、父函数的返回地址lr入栈（即x29与x30）。
  - stp x29, x30, [sp, #-48]!保护FP、lr以及函数栈的分配
- x18～x28中后续函数体要用到的寄存器进行入栈保存，如果用不到则不用入栈保存
  - stp x19, x20, [sp, #16]
- 如果x0～x7中为函数传参则也需要将对应的寄存器进行保存（一般保存到x18～x26寄存器中），参数的传递一般是前8个参数由x0～x7寄存器，后面的参数都有栈进行传递。所以在被调用函数中如果要用到调用者传入的寄存器中的参数就需要保存。
  - mov w20, w1
  - mov x19, x2
  - 由于在该函数中并没有用到第一个参数，所以编译器就进行优化了，没有进行x0寄存器值保存。
在上面的现场保存后函数栈的分布如下图：

在这里插入图片描述

然后跳转到_mcount

.macro mcount_enterstp	x29, x30, [sp, #-16]!mov	x29, sp
.endm

SYM_FUNC_START(_mcount)mcount_enterldr_l	x2, ftrace_trace_functionadr	x0, ftrace_stubcmp	x0, x2			// if (ftrace_trace_functionb.eq	skip_ftrace_call	//     != ftrace_stub) {mcount_get_pc	x0		//       function's pcmcount_get_lr	x1		//       function's lr (= parent's pc)blr	x2			//   (*ftrace_trace_function)(pc, lr);skip_ftrace_call:			// }
#ifdef CONFIG_FUNCTION_GRAPH_TRACERldr_l	x2, ftrace_graph_returncmp	x0, x2			//   if ((ftrace_graph_returnb.ne	ftrace_graph_caller	//        != ftrace_stub)ldr_l	x2, ftrace_graph_entry	//     || (ftrace_graph_entryadr_l	x0, ftrace_graph_entry_stub //     != ftrace_graph_entry_stub))cmp	x0, x2b.ne	ftrace_graph_caller	//     ftrace_graph_caller();
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */mcount_exit
SYM_FUNC_END(_mcount)

进去也是对x29, x30(FP 和 LR)进行保存（FP为栈基指针）
这时候的栈分布如下图：

在这里插入图片描述

对mcount_get_pc x0指令取到追踪函数B的地址的分析：
- mcount_get_pc x0 -> ldr x0, [x29, #8]可以看出是FP_M + 8的地址处的值给x0，即LR_B给到x0，刚好LR_B就是B中bl _mcount指令下一条指令地址。
对mcount_get_lr x1指令取到调用者函数的地址的分析：
- mcount_get_lr x1 -> ldr x1, [x29] 以及 ldr x1, [x1, #8]，可以看出第一条指令ldr x1, [x29]从FP_M的地址处取到内容FP_B存到x1中，然后第二条指令ldr x1, [x1, #8]从x1 + 8（= FP_B + 8）地址处取到内容LR_A给到x1，这样就取到了A的LR地址，即调用者函数的返回地址。

经过上面的分析可以看到对于调用者A以及被追踪者B函数的内容以及返回地址都可以拿到并保存。
接下来就是进入对应的追踪器执行。
1. 保存必要的信息，比如LR_A、LR_B、FP_A、FP_B等，并做其他ftrace的信息处理，然后将BL到LR_B中继续执行完B函数（进入B函数时LR寄存器的地址为实际trace回调函数中的地址）。
2. 当B函数执行完后，返回到trace回调函数，在trace函数中做该被追踪函数B的记录结尾，然后将直接返回到函数A继续执行了。
对于超过8个参数的参数读取也不受限制，直接通过父函数的FP指针访问（并没有破坏该函数的栈）。
至此bl _mcount机制的实现原理已经解释完，其他的就是对ftrace具体回调函数中的一些工作，这里就不再说明（主要是记录函数调用运行的一些信息，并放入到ring buf中，开放应用层接口供应用层查看）。大致跳转流程图如下：

在这里插入图片描述