今天对ftrace可视化工具进行了重大改造，提升了代码定位的准确性，此外处理性能也得到指数级的提高。

首先是提高了代码定位的准确性。做这个工具的初衷就是希望让全球广大Linux内核爱好者在看trace时可以很容易定位当前函数具体是在代码的哪一行调用的，这对于梳理代码执行流程至关重要。而funcgraph-retaddr输出的是函数的返回地址，直接对这个地址调用addr2line显然不满足我们的要求。根据函数调用的原理，在执行函数调用指令时，CPU会自动保存下一条指令的地址，因此解决方案也非常简单粗暴，直接对返回地址减去一定数值得到前一条指令的起始地址，可是具体减多少呢？对于ARM64架构，每条指令固定占4字节，所以减4可以。但是对于像x86架构这种变长指令集，就不好确定了。我的AI知识库说addr2line不需要精确的指令起始地址，只需落在某行代码对应的指令范围内即可正确映射，这个工具的设计初衷就是处理近似地址(如Oops中的函数+偏移)，为的是方便调试。所以统一减1就可以保证得到的地址落在前一条指令的范围内(DWARF规范也是这么推荐的)，再调用addr2line就可以得到当前函数被调用的准确位置。

然后就是大幅提高了解析trace文件的性能。目前根据地址解析得到代码行调用的是内核的faddr2line工具，它是用bash脚本语言编写的，执行的时候调用了很多三方的工具，比如readelf、grep以及awk等，同时它内部使用了多个循环遍历的算法(O(N))，对于处理像vmlinux这种包含几十万个函数符号的ELF文件来说就非常不合适。所以用python语言对这个工具进行了重写，不再调用三方的工具（仅保留addr2line），同时引入了多个二分搜索算法(O(LogN))，使文件的处理性能得到指数级的提高。以处理一个40行的trace文件为例，如果使用传统的faddr2line的话，需要大约54秒，而重写后仅需6秒。处理1000行trace日志，耗时也只有7秒，大部分时间（5秒多）都消耗在启动时解析vmlinux，构建内部数据结构上了。

虽然全程都是让AI编码，但需要自己对整个流程有一个清晰的理解，然后给AI提出需求，AI写完后还需要人工走读，发现待优化的点，让AI继续优化，前后折腾了有将近30版。

目前我在gitee上给这个工具建立了一个仓库，方便后续继续完善，项目地址是：https://gitee.com/pengdonglin137/FuncGraph