gcc profiling的工作原理
gcc profiling的工作原理
转载时请注明出处和作者联系方式：http://blog.csdn.net/absurd
作者联系方式：Li XianJing <xianjimli at hotmail dot com>
更新时间：2006-1-8
gcc profiling是一个常用的功能，本来没有什么好说的。不过最近想知道GTK+ + DirectFB应用程序起动缓慢的原因，打算让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 total 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 total 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。
l monstartup是初始化函数。它有两个参数：lowpc和 highpc。我们知道pc是程序计数器，lowpc/ highpc指向代码段的开始和结束。在csu/gmon-start.c中得到了证实：lowpc=_start，而highpc=etext。
l mcleanup是退出函数。它负责保存profiling数据。数据分为histogram、call-graph和basic-block三类。Histogram描述每一段指令执行的情况，call-graph描述调用关系和调用次数，basic-block描述每条语句的执行情况。gcc 4.00并不支持-a选项，估计basic-block不会工作。
l moncontrol是一个有趣的函数，它真正控制profiling的开始和结束。它用不同的参数调用了__profil，以决定是开始还是结束。起初我猜测__profil是系统调用，不过在kernel里没有发现它的实现。
5. 最后在sysdeps/posix/profil.c中找到了__profil的实现。
l __profil 的实现很简单，用setitimer设置一个定时器，定时器到了之后，系统会给该进程发送SIGPROF信号。
l 在profil_counter是SIGPROF信号的处理函数，profil_counter调用profil_count记录数据。
6. 可能只有明白了__profil的参数后才会清楚profil_count的实现。
l sample_buffer: 很明显是用于记录采样数据的buffer，在profil_count函数中也可以得到证实。
l size: sample_buffer的大小。
l offset: 是代码段的起始位置，在moncontrol中可以得到证实，offset= lowpc。
l scale: 这个参数有点让人费解了。再回去看看profil_count的实现，才知道profil_count中是以64K长度为统计单位的，64K长的代码可以包含上百个数函数，所以无疑粒度太大了。scale就是用来控制统计粒度的，scale=1表示以64K为采样单位，scale=64K表示以一个字节为采样单位。实际的采样粒度是在monstartup中指定的，它根据代码段的大小决定。
有了这些数据和setitimer的时间间隔，就不难得到profiling数据。
7. 我们知道了gcc profiling的工作原理，再回过头来看看原来的问题: gcc profiling是否支持共享库。答案是：不支持。证据有：
l monstartup的参数lowpc和highpc，限制了只能对一个代码段进行profiling。而共享库的代码段往往是映射到不同的区间的。
l profil_count 中的(i < nsamples)条件，过滤了对共享库函数的时间统计。
l mcount中的(frompc > p->textsize) 条件，过滤了对共享库函数的调用次数统计。
从代码可以看出gcc profiling对多线程的处理也有问题。多线程和共享库这么重要的问题都不解决，那gcc profiling到底有多用处？不明白gcc profiling的实现者是如何考虑的。通过LD_PRELOAD自己实现mcount和SIGPROF信号处理函数并不复杂，但是真的非要自己写吗？
~~end~~
