一文搞懂 | Ftrace 的实现原理

阳光穿透心脏的1/2处 2022-09-10 06:20 214阅读 0赞

## arm64 栈帧结构 ##

arm64 有31个通用寄存器 r0-r30，用法分别如下：

<table> 
 <thead> 
  <tr> 
   <th>寄存器</th> 
   <th>意义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SP</td> 
   <td>Stack Pointer: 栈指针</td> 
  </tr> 
  <tr> 
   <td>r30</td> 
   <td>Link Register: 在调用函数时候，保存下一条要执行指令的地址</td> 
  </tr> 
  <tr> 
   <td>r29</td> 
   <td>Frame Pointer:保存函数栈的基地址</td> 
  </tr> 
  <tr> 
   <td>r28...r19</td> 
   <td><br></td> 
  </tr> 
  <tr> 
   <td>r18</td> 
   <td><br></td> 
  </tr> 
  <tr> 
   <td>r17</td> 
   <td><br></td> 
  </tr> 
  <tr> 
   <td>r16</td> 
   <td><br></td> 
  </tr> 
  <tr> 
   <td>r15...r9</td> 
   <td>临时寄存器</td> 
  </tr> 
  <tr> 
   <td>r8</td> 
   <td>在一些情况下，返回值是通过 r8 返回的</td> 
  </tr> 
  <tr> 
   <td>r7...r0</td> 
   <td>在函数调用过程中传递参数和返回值</td> 
  </tr> 
  <tr> 
   <td>NZCV</td> 
   <td>状态寄存器：N（Negative）负数 Z(Zero) 零 C(Carry) 进位 V(Overflow) 溢出</td> 
  </tr> 
 </tbody> 
</table>

下面以如下代码为例，说明它的栈帧结构：

int fun2(int c,int d)
    {
       return0;
    }
     
    int fun1(int a,int b)
    {
       int c = 1;
       int d = 2;
      
       fun2(c, d);
       return0;
    }
     
    int main(int argc,char **argv)
    {
       int a = 0;
       int b = 1;
       fun1(a,b);
    }

其反汇编后的结果和对应栈帧结构为：

![722a28d6f055c3795a520cdcee5cc454.png][]

其详细步骤如下：

1.  每个函数在入口处首先会分配栈空间，且一次分配，确定栈顶，之后sp将不再变化；
2.  每个函数的栈顶部存放的是caller的栈顶指针，即fun1的栈顶存放的是main栈顶指针;
3.  对于最后一级callee函数，由于x29保存了上一级caller的栈顶sp指针，因此不在需要入栈保存，如示例中fun2执行时，此时x29指向fun1的栈顶sp

## 编译阶段 ##

以 blk\_update\_request 为例，看下其开启 Ftrace 前后的反汇编代码:

![c1eb14289185ec82c20205e3a4337902.png][]

可以看出，右图中多插入了一段【3f3c: 94000000 bl 0 <\_mcount>】，那么是由谁何时插入的呢？

编译选项 -pg -mrecord-mcoun 会在编译时，在每个可 trace 的函数插入 bl 0 <\_mcount>。

## 链接阶段 ##

![e1f5ceb86d44aa22e4a6289cbd003315.png][]

可以看出编译阶段的【3f3c: 94000000 bl 0 <\_mcount>】，在链接阶段变成了【ffff8000104e43f4: 97ed1fde bl ffff80001002c36c <\_mcount>】。

其中 \_mcount 函数反汇编为：

ffff80001002c36c <_mcount>:
    ffff80001002c36c:       d65f03c0        ret

## 运行阶段 ##

### ftrace\_init 执行后的 blk\_update\_request ###

![a7250b8183efd74a0a4d0ede8b31fb46.png][]

可见，内核在 start\_kernel 执行时，会调用 ftrace\_init，它会将所有可 trace 函数中的 \_mcount 进行替换，如上可以看出链接阶段的 【bl ffff80001002c36c <\_mcount>】 已经被替换为 【nop】 指令。

### 设定 trace 后的 blk\_update\_request ###

先执行如下命令来 trace 函数 blk\_update\_request：

> $echo blk\_update\_request > /sys/kernel/debug/tracing/set\_ftrace\_filter
> 
> $echo function > /sys/kernel/debug/tracing/current\_tracer

然后再来查看blk\_update\_request反汇编代码：

![31c30afbc0aea7341e7f29b0f780d491.png][]

可以看到之前在 blk\_update\_request 的 【nop】 指令被替换成 【bl 0xffff80001002c370 <ftrace\_caller>】。**函数 ftrace\_caller 将调用用户注册的 trace 函数。**

## 总结 ##

1.  编译阶段。通过编译选项 -pg -mrecord-mcount 在每个支持 trace 的函数中插入 bl 0 <\_mcount> 指令。
2.  链接阶段。会根据重定位段将 bl 0 <\_mcount> 指令地址重定位为 \_mcount 函数地址。
3.  运行阶段。

> (1). ftrace\_init：会将可 trace 函数中的 【bl 0 <\_mcount>】 替换为 【nop】 指令；
> 
> (2). 执行 echo blk\_update\_request > set\_ftrace\_filter：会使能 blk\_update\_request 的钩子函数替换标记（nop 替换为 ftrace\_caller）;
> 
> (3). 执行 echo function > current\_tracer：将 ftrace\_caller 中 ftrace\_call 被替换为 ftrace\_ops\_no\_ops，最终会调用到 function\_trace\_call。

![f1961223d9d80810842c2b315136adfe.png][]

![虚线阴影分割线][fcd3085c8144af9c720f651bd64e47bd.png]

5T技术资源大放送！包括但不限于：C/C++，Arm, Linux，Android，人工智能，单片机，树莓派，等等。在上面的【人人都是极客】公众号内回复「peter」，即可免费获取！！

![3c7f5eb81ffb2e0a2c0a83599c2dbfd8.gif][] **记得点击****分享****、****赞****和****在看****，给我充点儿电吧**

[722a28d6f055c3795a520cdcee5cc454.png]: /images/20220829/a61b2c32b6b64c4bbde509d85051b476.png
[c1eb14289185ec82c20205e3a4337902.png]: /images/20220829/3aae916033fa4be3939b82c511fb4650.png
[e1f5ceb86d44aa22e4a6289cbd003315.png]: /images/20220829/f157b03f74fe4aa59a6c088322c625f0.png
[a7250b8183efd74a0a4d0ede8b31fb46.png]: /images/20220829/1b8445ca40e04dcc8d62697b00f48f5a.png
[31c30afbc0aea7341e7f29b0f780d491.png]: /images/20220829/e21ea884a3634b15ba5e179f376c68c0.png
[f1961223d9d80810842c2b315136adfe.png]: /images/20220829/585d0e30a272422e82725c5d107b7eb3.png
[fcd3085c8144af9c720f651bd64e47bd.png]: /images/20220829/f2979f10dd1f4fbbbea33ffa417a7c43.png
[3c7f5eb81ffb2e0a2c0a83599c2dbfd8.gif]: /images/20220829/7e384ab58bd44d0aa00b5d1bb78d15c6.png