当我们拿到一个比较大的项目源码时,往往需要总览代码的结构,理清脉络,发现核心点。如果没有前人给出的经验,我们该如何找到关键的函数和模块呢?这个时候我们就可以借助一些工具来生成“调用图”(Call Graph)。图中函数和模块的连线比较多,说明其被使用的很多,需要重点关注;图中函数和模块位于很多调用栈中,说明该函数是有关“脉络”的信息,也要重点关注。
比如event_add被连接很多,说明被使用的地方很多,需要重点关注;event_base_dispatch和event_base_loop位于一个流程的前端,说明可能是构成我们业务逻辑脉络的主体前部。
我梳理并实验了各种主流的方案,本文进行一些总结。
目前的技术流派主要分为两种:
优点:
缺点:
语法树解释器是静态代码分析的关键。我主要关心的是两点:
目前解释器分为两类:
calltree和cflow有自己的代码解释器,所以完全不需要编译代码就可以进行分析。目前看,cflow还在更新中,calltree已经很古老了。所以推荐使用cflow。
cally和egypt并不自己分析代码,它们需要借助gcc编译出RTL(Register transfer language)文件,所以要求这些代码可以被编译。这些工具会分析产出的RTL文件产出调用关系,所以可以称之为“调用关系分析器”。个人觉得egypt比cally优秀,因为它可以分析出更加复杂的调用关系。
callgraph-info-combiner则更近一步,它直接使用GCC产出的文件内调用关系,重新整合出整个项目的调用关系。
动态代码分析更多来源于很多性能分析工具。它们不仅可以分析出函数调用关系,还能分析出各个模块的运行状态。
优点:
缺点:
主要就是有哪些性能分析工具:
它们细微的区别是:
这些都是很优秀的库,如果一定要选一个,我只能从易用性上考虑,推荐perf。
建议的决策树如下