基于ptrace开发自定义profiler时如何获取call指令调用的函数符号

完全可以在识别相对call指令时直接拿到跳转目标地址甚至对应符号名，根本不需要等指令执行完成后再读RIP反推。
针对32位x86架构下的近相对调用（也就是操作码0xE8的call rel32指令）：

• 这类指令固定长度为5字节，格式为1字节操作码 + 4字节有符号32位相对偏移，你仅处理相对调用的场景下，只需要识别这一类操作码的指令即可，不需要处理远调用、间接调用的解码逻辑
• 当ptrace单步捕捉到RIP指向这条call指令的首地址时，直接通过PTRACE_PEEKDATA读取该位置开始的5字节指令，按照目标地址 = 当前RIP + 5 + 指令内的有符号偏移的公式，就能直接算出call要跳转的函数地址
• 将算出的地址和你提前用nm提取的符号地址表做匹配，就能直接拿到对应的函数符号名，完全不需要等call执行完再判断RIP所属的函数范围

你目前设计的“全量单步遍历所有指令、识别call/ret动作”的方案，理论上能实现基础功能，但存在几个硬伤，完全不适合作为prof工具的正式实现：

• 全量单步的性能开销极高：32位x86下每条指令执行完都会触发一次内核态ptrace陷阱，上下文切换开销会把被追踪程序的运行速度压到正常状态的1%以下，完全失去性能统计的参考价值
• 现有符号匹配逻辑容易出错：如果依赖call执行完后的RIP地址判断所属函数，在静态链接的二进制中，遇到薄壳函数、对齐填充的地址空洞时，很容易出现符号匹配错位，尤其是递归、嵌套调用场景下，错位会不断累积
• 指令统计逻辑开销过大：如果要逐单步累计每条指令的执行数，在记录函数执行周期的场景下，需要反复判断当前函数栈深度的变化，这部分逻辑的运行开销会被单步模式放大到完全不可接受的程度

针对静态链接32位x86环境下的动态调用树生成、函数指令数统计需求，通用实现不会采用全量单步的思路，而是采用断点+少量单步的混合方案：

1. 提前用nm提取所有自定义函数的符号地址范围，构建两个核心映射表：
   • 地址到函数名的快速查找表，支持根据任意地址快速匹配所属函数
   • 所有函数入口地址的清单
2. 通过ptrace在每一个函数的入口地址处写入临时int3断点（单字节0xCC指令），替换原入口位置的指令字节
3. 当被追踪进程执行到断点位置触发陷阱时，依次完成以下动作：
   • 把断点位置的原指令恢复回内存，触发一次单步执行让原指令运行完成，再把断点重新写回原位置，保证后续同函数被调用时依然能被捕捉到
   • 读取栈上存储的返回地址，结合当前匹配到的函数名，把本次调用关系压入自维护的调用栈，同时记录当前的全局指令累计值作为本次函数执行的起点
   • 当程序执行返回、栈指针弹出对应函数帧时，用全局指令累计值减去之前记录的起点值，就能得到该函数本次执行一共耗费的指令数量
4. 所有相对call、甚至间接call的目标地址，不需要你手动解码指令——只要调用目标是你提前识别到的函数，最终都会触发函数入口的断点，直接就能拿到准确的调用关系，完全省去了逐指令扫描、解码call操作数的开销

补充说明：你觉得ptrace官方文档表述模糊很正常，文档本身只是罗列了每个接口的机械参数，实际开发profiling工具时，根本不会把PTRACE_SINGLESTEP接口用来做全量指令遍历——组合使用断点陷阱捕捉、内存读写、寄存器读写、定点单步这几个基础能力，就足够实现所有上述功能，不需要纠结单步接口的细枝末节。

内容的提问来源于stack exchange，提问作者Desperados