gcc profiling的工作原理

所谓的profiling，就是分析程序中的各个函数的调用次数和运行时间，以找到程序的热点，为优化程序提供依据。gcc的profiling功能更强大一点，它还可以显示调用关系(call graph)。它的用法如下：

1. 编译/链接时加-pg标志。

gcc -pg -g main.c test.c -o test

2. 运行程序。

./test

3. 分析数据。

gprof –b test

结果：

Each sample counts as 0.01 seconds.
%   cumulative   self              self     totao
time   seconds   seconds    calls  ms/call  ms/call  name
100.72      0.07     0.07        1    70.50    70.50  test
…

够简单吧! 不过当我把test.c编译成一个共享库时，就遇到了麻烦：

1. 编译。

gcc -pg -g test.c -shared -o libtest.so

gcc -pg -g main.c -L./ -ltest -o test

2. 运行程序。

./test

3. 分析数据。

gprof -b test

结果:

Each sample counts as 0.01 seconds.
no time accumulated
%   cumulative   self              self     totao
time   seconds   seconds    calls  Ts/call  Ts/call  name
…

前面的分析数据现在没了，你说奇怪不？难道gcc profiling不支持共享库？查了一个资料，即没有找到gcc profiling不支持共享库的论断，也没有找到支持共享库的方法。只好去自己去分析。

1. 先反汇编，观察gcc对源代码的处理。

objdump -S test

我们可以看到，gcc在每个函数里都加了call 804841c mcount@plt。可以猜测mcount是用来统计函数调用次数的。

2. 用gdb在mcount处设置断点。

Breakpoint 3, 0x001de9b0 in mcount () from /lib/libc.so.6

正如所料的，mcount是在libc中实现的。

3. 在glibc中找到mcount的源代码(gmon/mcount.c)

mcount的实现有点复杂，它的功能正是增加函数调用次数count的。

4. mcount记录了函数的调用次数，但运行时间是如何确定的呢？接下又看了gmon.c。

o monstartup是初始化函数。它有两个参数：lowpc和 highpc。我们知道pc是程序计数器，lowpc/ highpc指向代码段的开始和结束。在csu/gmon-start.c中得到了证实：lowpc=_start，而highpc=etext。

o mcleanup是退出函数。它负责保存profiling数据。数据分为histogram、call-graph和basic-block三类。 Histogram描述每一段指令执行的情况，call-graph描述调用关系和调用次数，basic-block描述每条语句的执行情况。gcc 4.00并不支持-a选项，估计basic-block不会工作。

o moncontrol是一个有趣的函数，它真正控制profiling的开始和结束。它用不同的参数调用了__profil，以决定是开始还是结束。起初我猜测__profil是系统调用，不过在kernel里没有发现它的实现。

5. 最后在sysdeps/posix/profil.c中找到了__profil的实现。

o __profil 的实现很简单，用setitimer设置一个定时器，定时器到了之后，系统会给该进程发送SIGPROF信号。

o 在profil_counter是SIGPROF信号的处理函数，profil_counter调用profil_count记录数据。

6. 可能只有明白了__profil的参数后才会清楚profil_count的实现。

o sample_buffer: 很明显是用于记录采样数据的buffer，在profil_count函数中也可以得到证实。

o size: sample_buffer的大小。

o offset: 是代码段的起始位置，在moncontrol中可以得到证实，offset= lowpc。

o scale: 这个参数有点让人费解了。再回去看看profil_count的实现，才知道profil_count中是以64K长度为统计单位的，64K长的代码可以 包含上百个数函数，所以无疑粒度太大了。scale就是用来控制统计粒度的，scale=1表示以64K为采样单位，scale=64K表示以一个字节为 采样单位。实际的采样粒度是在monstartup中指定的，它根据代码段的大小决定。

有了这些数据和setitimer的时间间隔，就不难得到profiling数据。

7. 我们知道了gcc profiling的工作原理，再回过头来看看原来的问题: gcc profiling是否支持共享库。答案是：不支持。证据有：

o monstartup的参数lowpc和highpc，限制了只能对一个代码段进行profiling。而共享库的代码段往往是映射到不同的区间的。

o profil_count 中的(i < nsamples)条件，过滤了对共享库函数的时间统计。

o mcount中的(frompc > p->textsize) 条件，过滤了对共享库函数的调用次数统计。

从代码可以看出gcc profiling对多线程的处理也有问题。多线程和共享库这么重要的问题都不解决，那gcc profiling到底有多用处？不明白gcc profiling的实现者是如何考虑的。通过LD_PRELOAD自己实现mcount和SIGPROF信号处理函数并不复杂，但是真的非要自己写吗？

附：
后来发现的两个性能分析工具：
Oprofile:
sysprof: ~sandmann/sysprof/

转自：http://www.limodev.cn/2009/03/10/gcc-profiling%E7%9A%84%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/