IT项目研发过程中的利器——C/C++项目调用图篇

当我们拿到一个比较大的项目源码时，往往需要总览代码的结构，理清脉络，发现核心点。如果没有前人给出的经验，我们该如何找到关键的函数和模块呢？这个时候我们就可以借助一些工具来生成“调用图”（Call Graph）。图中函数和模块的连线比较多，说明其被使用的很多，需要重点关注；图中函数和模块位于很多调用栈中，说明该函数是有关“脉络”的信息，也要重点关注。

比如event_add被连接很多，说明被使用的地方很多，需要重点关注；event_base_dispatch和event_base_loop位于一个流程的前端，说明可能是构成我们业务逻辑脉络的主体前部。

我梳理并实验了各种主流的方案，本文进行一些总结。

目前的技术流派主要分为两种：

• 静态代码分析：指不需要代码运行，仅仅是通过对源码的解析来分析它们的调用关系。
• 动态代码分析：是指需要编译代码，甚至要插入一些特殊代码到编译结果中。然后监控运行过程，产出调用关系。

静态代码分析

优缺点

优点：

• 可以全面分析代码。哪怕一些函数在项目中没有使用，也可以被分析出来。

缺点：

• 鉴于编译过程的复杂，以及C/C++语言中指针的灵活使用。静态代码很难100%准确分析出整个项目的调用图。

解释器

语法树解释器是静态代码分析的关键。我主要关心的是两点：

1. 准确性。这个并不好评估，但是可以做些实验得出结论。
2. 继续更新和维护。这个直接看其更新进度就能评估。

目前解释器分为两类：

1. 自维护。即自己编写语法树的解释逻辑。代表有calltree（《静态分析C语言生成函数调用关系的利器——calltree》）和cflow（《静态分析C语言生成函数调用关系的利器——cflow（二）》）。
2. 第三方。主要使用gcc进行解释。代表有cally、egypt（《静态分析C语言生成函数调用关系的利器——cally和egypt》）和我写的callgraph-info-combiner（《静态分析C语言生成函数调用关系的利器——GCC》）。

calltree和cflow有自己的代码解释器，所以完全不需要编译代码就可以进行分析。目前看，cflow还在更新中，calltree已经很古老了。所以推荐使用cflow。

cally和egypt并不自己分析代码，它们需要借助gcc编译出RTL（Register transfer language）文件，所以要求这些代码可以被编译。这些工具会分析产出的RTL文件产出调用关系，所以可以称之为“调用关系分析器”。个人觉得egypt比cally优秀，因为它可以分析出更加复杂的调用关系。

callgraph-info-combiner则更近一步，它直接使用GCC产出的文件内调用关系，重新整合出整个项目的调用关系。

动态代码分析

动态代码分析更多来源于很多性能分析工具。它们不仅可以分析出函数调用关系，还能分析出各个模块的运行状态。

优缺点

优点：

• 准确。因为是在运行时进行的记录，所以它的分析是准确的。因为谁调用谁，谁被谁调用都是在运行过程中被记录的。

缺点：

• 不全面。它只能分析运行过的函数，对于运行没有覆盖的函数，不能分析出来。

技术流派

主要就是有哪些性能分析工具：

1. perf。《动态分析C语言代码生成函数调用关系的利器——perf》
2. gprof。《动态分析C语言代码生成函数调用关系的利器——gprof》
3. valgrind。《动态执行流程分析和性能瓶颈分析的利器——valgrind的callgrind》
4. gperftools。《动态执行流程分析和性能瓶颈分析的利器——gperftools的Cpu Profiler》

它们细微的区别是：

• gprof和gperftools需要在编译时链接分析库的代码；而perf和valgrind则不需要。

这些都是很优秀的库，如果一定要选一个，我只能从易用性上考虑，推荐perf。

决策树

建议的决策树如下