关于C++ code coverage tool 的研究（2）—GCOV 实现原理
http://qa.taobao.com/?p=8451
1、背景介绍
GCOV是一个GNU的本地覆盖测试工具, 伴随GCC发布，配合GCC共同实现对C或者C++文件的语句覆盖和分支覆盖测试。是一个命令行方式的控制台程序。需要工具链的支持。
LCOV由 IBM 开发，由 Linux Test Project 维护的开放源代码工具。是GCOV结果展现的一个前端。这个工具由一组构建于基于文本的GCOV 输出之上的 PERL 脚本构成，以实现基于 HTML 的输出, 并生成一棵完整的 HTML 树。输出包括覆盖率百分比、图表以及概述页，可以快速浏览覆盖率数据。支持大项目，提供三种等级视图，分别为目录视图，文件视图，源代码视图。
2、GCOV分析
2.1 基本概念
1． 基本块BB
如果一段程序的第一条语句被执行过一次，这段程序中的每一个都要执行一次，称为基本块。一个BB中的所有语句的执行次数一定是相同的。一般由多个顺序执行语句后边跟一个跳转语句组成。所以一般情况下BB的最后一条语句一定是一个跳转语句，跳转的目的地是另外一个BB的第一条语句，如果跳转时有条件的，就产生了分支，该BB就有两个BB作为目的地。
下图是个典型的基本块：
2．跳转ARC
从一个BB到另外一个BB的跳转叫做一个arc,要想知道程序中的每个语句和分支的执行次数，就必须知道每个BB和ARC的执行次数
3. 程序流图
如果把BB作为一个节点，这样一个函数中的所有BB就构成了一个有向图。,要想知道程序中的每个语句和分支的执行次数，就必须知道每个BB和ARC的执行次数。根据图论可以知道有向图中BB的入度和出度是相同的，所以只要知道了部分的BB或者arc大小，就可以推断所有的大小。
这里选择由arc的执行次数来推断BB的执行次数。
所以对部分 ARC插桩，只要满足可以统计出来所有的BB和ARC的执行次数即可。
以下是针对某个函数的程序流图：
2.2 GCOV原理与实现
2.2.1原理简介
GCOV是一个纯软件的覆盖测试工具，被测程序的预处理，插桩和编译成目标文件三个步骤由GCC一次完成。GCOV本身只负责数据处理和结果显示，下图是GCOV的工作原理。
gcov工作原理
从左图可以看出，GCOV统计覆盖率主要包括三个阶段：
l 编译阶段：
加入编译选项gcc –o hello –fprofile-arcs –ftest-coverage hello
除了为每个C文件生成*.o目标文件以外还要生成数据文件*.bb和*.bbg(在早期的GCC版本中是包含这两个文件，后期变成*.gcno文件，但是内部仍然包含这两个文件的结构)，分别记录行信息和程序流图信息，供GCOV计算覆盖率时用。
l 数据收集与提取阶段：
./hello 执行时收集数据。
被测程序运行后为每个源文件生成一个*.da数据文件，后期编译器成为.gcda文件，分别记录了*.c文件中程序的执行情况。
l 报告形成阶段：
gcov –a hello.c 收集某个源文件的覆盖率情况
执行后会生成输出文件覆盖率情况，可以重定向保存到某个文件中，同时生成hello.c.gcov形式的文件，文件格式是带有标示信息的源文件。
从右边图可以看出，GCOV的插桩时段，是在编译阶段完成：
被测程序文件首先经过编译预处理，然后编译成汇编文件，在生成汇编文件的同时完成插桩。插桩是在生成汇编文件的阶段完成的，因此插桩是汇编时候的插桩，每个桩点插入3~4条汇编语句，直接插入生成的*.s文件中，最后汇编文件汇编生成目标文件。在程序运行过程中桩点负责收集程序的执行信息。
2.2.2 覆盖率收集过程
gcov的实现源文件包括：coverge.c, gcov.c, gcov-io.c, libgcov.c, profile.c ，libgcc2.c以及他们的头文件，以下从具体的三个阶段来讨论覆盖率收集的过程。
1、编译阶段
在编译阶段，当加入相应的编译选项后，由toplev.c中的函数调用coverage.c与profile.c中的函数，这些函数又调用gcov-io.c中的函数。其中coverage.c中的build_gcov_info 产生一些数据结构，并调用gcov_init 。 同时profile.c会创建程序流图，由profile.c中的函数创建的程序流图，同时gcno中的每个arc会调用insert_insn_on_edge函数来增加counter.
2、数据收集阶段
在数据收集阶段，即在程序运行时。会调用libgcov.c中的函数来增加struct gcov_info的count字段的信息，当程序退出时，gcov_exit会被调用，这个函数将收集到的数据信息写入到.gcda文件中。
3、生成报告阶段
运行（$gcov 源文件）后就产生这个后缀文件。gcov要分析的话需要依赖于.gcno，.gcda,.c三个文件,记住这个分析一定要保证：.gcda产生的时候依赖的.gcno要一致，就是说我.gcda和.gcno一定要是配套的。
gcov的分析过程：（用.bbg与.bb代替.gcno来讲）
- gcov读取.bbg中的程序流图信息，建立被测源文件中每个函数的程序流图
- 读取.gcda信息，将已知的弧执行次数填入到程序流图中
- 根据节点入度等于出度的原理推算出其他的弧与基本块的执行次数
- 读取.bb文件，根本对应关系计算出每行代码的执行次数
- 对应分支的话还需要计算分支的起始位置
- 输出计算结果
2.2.3 插桩方法
现在为止，我们知道，
Gcc编译运行产生了什么数据以及gcov分析覆盖率的过程。
还有两个问题:
a. gcc加入编译参数后，是怎么插桩的
b. 在什么位置，插入了什么数据呢？
1． 插桩过程所进行的修改
1） 每个源文件对应桩点数组：
GCC在插桩的过程中会像源文件的末尾插入一个静态数组，BX2.，数组的大小就是这个源文件中桩点的个数。
BX2+0代表第0个桩点的位置，BX2+n代表第n个桩点的位置。
数组的值就是桩点的执行次数。
2） 每个桩点插入汇编语句：
按照我的理解插入的汇编语句是inc$(BX2+n).
3） BX2数组链表：
为了便于统计，gcc还将各个源文件中的BX2数组链接成一个链表，这个链表结构是在测试main函数之前就产生了，在调用main之前会有一个类似构造函数的函数，进行构建链表。这个函数会在退出时调用exit函数计算执行次数生成.gcda文件。
2． 一些数据结构与函数功能
1） BX2数组：
每个源文件对应一个，记录每个桩点的执行次数。
2） bb结构：
因为要将各个源文件的BX2组织起来，便于统一输出，为每个源文件定义一个bb结构如下：
struct bb
{
long zero_word; //是否被插入到链表中
const char *file_name; //当前被测试文件名
long *count;//指向bx2的指针
long ncounts;//桩点个数
struct bb *next;//下一个文件的BX2信息
};
3） BX链表：
将BX2组织起来，头指针bb_head，链表元素结构为bb结构。调用void _bb_init_func(struct bb * block), 传入头指针bb_head创建。
4） 创建链表过程：void _bb_init_func(struct bb * block)
GCC为被测源文件插入了一个构造函数_GLOBAL_$I$XXXGCOV()的定义，其中XXX指当前被测文件中的第一个全局函数的函数名的生成，此函数在main函数调用之前会同构造函数一起被调用，这个全局函数的功能就是调用_bb_init_func函数，以该文件的bb结构的起始地址为参数进行调用。
该函数定义在GCC自带的库文件Libgcc.a中，源码位于gcc/libgcc2.c中，定义如下：
void _bb_init_func(struct bb * blocks)
{
if(block->zero_word)//已经连接不管
Return;
if(!bb_head)
ON_EXIT(_bb_exit_func,0);//程序退出时候，写.gcda数据
blocks->zero_word=0;
blocks->next=bb_head;//插入到链表中
bb_head=blocks;
}
该函数首先检查bb结构是否被插入到链表中，如果是则返回，接着检查bb结构的链头是否被初始化，否则注册退出时执行函数_bb_exit_func，该函数负责返回bb链中的每个结构，并生成.gcda数据文件。
这样在main函数之前，所有的bb结构都被连接成一个链表。
5）写入数据文件的过程：_bb_exit_func（）
在被测程序运行完成之后，注册退出时会执行函数_bb_exit_func（），将从这个链表的头开始为每一个bb结构开始为源文件创建.gcda文件。写入的文件格式就是BX2数组内容，可以从bb结构中的BX2结构指针找到。
至此，整个插桩过程就讲完了。