企业网站系统详细设计,小说网站的网编具体做哪些工作,wordpress 样式表,上海有哪些软件公司Linux 内核调试工具ftrace 之#xff08;_mcount的实现原理#xff09;
ftrace 是 Linux 内核中的一种跟踪工具#xff0c;主要用于性能分析、调试和内核代码的执行跟踪。它通过在内核代码的关键点插入探针#xff08;probe#xff09;来记录函数调用和执行信息。这对于开…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* [functions 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 _mcountb78: 90000000 adrp x0, 0 __stack_chk_guardb7c: 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以及函数栈的分配 x18x28中后续函数体要用到的寄存器进行入栈保存如果用不到则不用入栈保存 stp x19, x20, [sp, #16] 如果x0x7中为函数传参则也需要将对应的寄存器进行保存一般保存到x18x26寄存器中参数的传递一般是前8个参数由x0x7寄存器后面的参数都有栈进行传递。所以在被调用函数中如果要用到调用者传入的寄存器中的参数就需要保存。 mov w20, w1mov x19, x2由于在该函数中并没有用到第一个参数所以编译器就进行优化了没有进行x0寄存器值保存。 在上面的现场保存后函数栈的分布如下图 然后跳转到_mcount
.macro mcount_enterstp x29, x30, [sp, #-16]!mov x29, sp
.endmSYM_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 // functions pcmcount_get_lr x1 // functions lr ( parents 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函数的内容以及返回地址都可以拿到并保存。接下来就是进入对应的追踪器执行。 保存必要的信息比如LR_A、LR_B、FP_A、FP_B等并做其他ftrace的信息处理然后将BL到LR_B中继续执行完B函数进入B函数时LR寄存器的地址为实际trace回调函数中的地址。当B函数执行完后返回到trace回调函数在trace函数中做该被追踪函数B的记录结尾然后将直接返回到函数A继续执行了。 对于超过8个参数的参数读取也不受限制直接通过父函数的FP指针访问并没有破坏该函数的栈。 至此bl _mcount机制的实现原理已经解释完其他的就是对ftrace具体回调函数中的一些工作这里就不再说明主要是记录函数调用运行的一些信息并放入到ring buf中开放应用层接口供应用层查看。大致跳转流程图如下 具体的ftrace操作
见文章《ftrace-内核调试工具》
