Chinaunix首页 | 论坛 | 博客
  • 博客访问: 295205
  • 博文数量: 43
  • 博客积分: 1044
  • 博客等级: 准尉
  • 技术积分: 658
  • 用 户 组: 普通用户
  • 注册时间: 2010-12-20 14:56
个人简介

人法地,地法天,天法道,道法自然。

文章分类

全部博文(43)

文章存档

2019年(1)

2013年(3)

2012年(15)

2011年(24)

分类: LINUX

2012-02-02 15:08:32

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

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

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

2. 运行程序。

  1. ./test

3. 分析数据。

  1. gprof –b test

结果:

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

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

1. 编译。

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

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

2. 运行程序。

  1. ./test

3. 分析数据。

  1. gprof -b test

结果:

  1. Each sample counts as 0.01 seconds.
  2. no time accumulated
  3. % cumulative self self totao
  4. time seconds seconds calls Ts/call Ts/call name

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

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

  1. objdump -S test

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

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

  1. 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/

阅读(3866) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~