模板
教程
环境
性能
功能
管理
Linux下c/c++项目代码覆盖率的产生方法(2)
基本块图(Basic Block Graph)，基本块的最后一条语句一般都要跳转，否则后面一条语句也会被计算为基本块的一部分。 如果跳转语句是有条件的，就产生了一个分支(arc)，该基本块就有两个基本块作为目的地。如果把每个基本块当作一个节点，那么一个函数中的所有基本块就构成了一个有向图，称之为基本块图(Basic Block Graph)。且只要知道图中部分BB或arc的执行次数就可以推算出所有的BB和所有的arc的执行次数;
打桩，意思是在有效的基本块之间增加计数器，计算该基本块被运行的次数;打桩的位置都是在基本块图的有效边上;
行覆盖率(line coverage)，源代码有效行数与被执行的代码行的比率;
分支覆盖率(branch coverage)，有判定语句的地方都会出现2个分支，整个程序经过的分支与所有分支的比率是分支覆盖率。注意，与条件覆盖率(condition coverage)有细微差别，条件覆盖率在判定语句的组合上有更细的划分。
2. gcc/g++ 编译选项
gcc需要静态注入目标程序编译选项，在编译链接的时候加入2个选项(-ftest-coverage -fprofile-arcs )，编译结束之后会生成 *.gcno 文件，而经过静态注入的目标程序在“正常结束”后，会在运行目录下产生*.gcda数据文件，通过gcov工具就可产生覆盖率数据结果。
-ftest-coverage
Produce a notes file that the gcov code-coverage utility (see gcov—a Test Coverage Program) can use to show program coverage. Each source file’s note file is called auxname.gcno. Refer to the -fprofile-arcs option above for a description of auxname and instructions on how to generate test coverage data. Coverage data matches the source files more closely if you do not optimize.
让编译器生成与源代码同名的.gcno文件(note file)，这种文件含有重建基本块依赖图和将源代码关联至基本块的必要信息;
-fprofile-arcs
Add code so that program flow arcs are instrumented. During execution the program records how many times each branch and call is executed and how many times it is taken or returns. When the compiled program exits it saves this data to a file called auxname.gcda for each source file. The data may be used for profile-directed optimizations (-fbranch-probabilities), or for test coverage analysis (-ftest-coverage). Each object file’s auxname is generated from the name of the output file, if explicitly specified and it is not the final executable, otherwise it is the basename of the source file. In both cases any suffix is removed (e.g. foo.gcda for input file dir/foo.c, ordir/foo.gcda for output file specified as -o dir/foo.o). See Cross-profiling.
让编译器静态注入对每个源代码行关联的计数器进行操作的代码，并在链接阶段链入经态度libgcov.a，其中包含在程序正常结束时生成*.gcda文件的逻辑;
下面通过源码解析来说明到底这2个选项做了什么。通过g++ -S选项，产生汇编语言Rectangle.s 和 Rectangle_cc.s (增加–coverage选项)，命令如下，
g++ -c -o Rectangle.s Rectangle.cpp -g -Wall -S
g++ -c -o Rectangle_cc.s Rectangle.cpp -g -Wall –coverage -S
vimdiff Rectangle.s 和 Rectangle_cc.s，如下图
通过这样汇编语言的对比，可以看出gcc通过这2个参数，把打桩的过程完成了。
更深入的内容，例如，如果想知道gcno/gcda文件的格式，可以参考 @livelylittlefish 的一篇文章，GCC Coverage代码分析-.gcda/.gcno文件及其格式分析(http://blog.csdn.net/livelylittlefish/article/details/6448885)。
四、扩展话题
通过上面三部分的介绍，相信绝大多数覆盖率问题都可以解决，下面2个问题是我们在实际运行过程中遇到的，也分享一下。
覆盖率的结果只有被测试到的文件会被显示，并非所有被编译的代码都被作为覆盖率的分母
实际上，可以看到整个覆盖率的产生的过程是4个步骤的流程，一般都通过外围脚本，或者makefile/shell/python来把整个过程自动化。2个思路去解决这个问题，都是通过外围的伪装。第一个，就是修改lcov的 app.info ，中间文件，找到其他的文件与覆盖率信息的地方，结合makefile，把所有被编译过的源程序检查是否存于 app.info 中，如果没有，增加进去。第二个伪装，是伪装 *.gcda，没有一些源码覆盖率信息的原因就是该文件没有被调用到，没有响应的gcda文件产生。toast(http://toast.taobao.org/)是通过第一种伪装来实现的，更多了解需要去看下开源代码。
2. 后台进程的覆盖率数据收集;
其实上述覆盖率信息的产生，不仅可以针对单元测试，对于功能测试同样适用。但功能测试，一般linux下c/c++都是实现了某个Daemon进程，而覆盖率产生的条件是程序需要正常退出，即用户代码调用 exit 正常结束时，gcov_exit 函数才得到调用，其继续调用 __gcov_flush 函数输出统计数据到 *.gcda 文件中。同样2个思路可以解决这个问题，
第一，给被测程序增加一个 signal handler，拦截 SIGHUP、SIGINT、SIGQUIT、SIGTERM 等常见强制退出信号，并在 signal handler 中主动调用 exit 或 __gcov_flush 函数输出统计结果。但这个需要修改被测程序。这个也是我们之前的通用做法。但参加过清无同学的一个讲座后，发现了下面第二种更好的方法。
第二，借用动态库预加载技术和 gcc 扩展的 constructor 属性，我们可以将 signalhandler 和其注册过程都封装到一个独立的动态库中，并在预加载动态库时实现信号拦截注册。这样，就可以简单地通过如下命令行来实现异常退出时的统计结果输出了。
