【问题标题】:Code compiled with profiling flag does not generate gmon.out使用分析标志编译的代码不会生成 gmon.out
【发布时间】:2015-01-21 05:19:59
【问题描述】:

我使用 profiling 标志 (-pg) 用 gcc 编译了一个代码,但是当我运行程序时没有生成 gmon.out。
我编译了一个 test 代码——实际上是来自this question 的代码——以查看编译标志和 gprof 是否正常工作,是的,它工作了。

为了编译代码(命名为xrttimetag),使用了以下行(下面我使用-I(...)-L(...) 来隐藏指向其他科学库的大量路径列表):

gcc -c  -o ./xrttimetag.o  -Wall --pedantic -Wno-comment -Wno-long-long -pg -fPIC -I(...) -DPACKAGE_NAME="" -DPACKAGE_TARNAME="" -DPACKAGE_VERSION="" -DPACKAGE_STRING="" -DPACKAGE_BUGREPORT="" -DPACKAGE_URL="" -Dg77Fortran=1 -DgFortran=1 -DHAVE_CONNECT=1 -DHAVE_ACCEPT=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBNCURSES=1 -DSIZEOF_LONG=8 xrttimetag.c

gcc -o xrttimetag xrttimetag.o      -L(...) -lswxrt -latFunctions3.3 -lcoordfits -lcoord -lephemeris -lhdinit_2.7 -lhdutils_2.7 -lape_2.8 -lcfitsio_3.37 -lreadline -lhdio_2.7 -lncurses -ldl -lm  -L/usr/lib64/gcc/x86_64-suse-linux/4.6 -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../.. -L/usr/lib64/gcc/x86_64-suse-linux/4.6 -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.6/../../.. -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc 

我在生成的二进制文件中查找与gmon 相关的符号,它们对我来说有点奇怪,因为它们是未定义

readelf -s `which xrttimetag` | egrep "gmon|mcount"
 21: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
 74: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mcount@GLIBC_2.2.5 (2)
 41: 000000000040267c     0 FUNC    LOCAL  DEFAULT   15 call_gmon_start
 96: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
166: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mcount@@GLIBC_2.2.5

另一方面,test 代码,我编译时使用:

g++ -pg test.cpp

搜索“gmon|mcount”符号给了我:

readelf -s test | egrep "gmon|mcount"
 6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mcount@GLIBC_2.2.5 (3)
11: 0000000000400850    63 FUNC    GLOBAL DEFAULT   15 __gmon_start__
40: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS gmon-start.c
43: 0000000000400890     0 FUNC    LOCAL  DEFAULT   15 call_gmon_start
73: 0000000000400850    63 FUNC    GLOBAL DEFAULT   15 __gmon_start__
91: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mcount@@GLIBC_2.2.5

我们可以为_test_代码而不是_xrttimetag_定义了“gmon”符号,但我真的不明白为什么。我错过了什么?

谢谢。

PS:我看到了gmon.out is not written after compiling with gcc -pg -g的问题,这个不是重复的,除非我完全误解了那个。

【问题讨论】:

  • 我遇到了完全相同的问题.. 很好的问题描述和答案!

标签: c++ c gcc profiling gprof


【解决方案1】:

生成可执行文件时您没有传递-pg

gcc -o xrttimetag xrttimetag.o ....

你也应该在这里传递-pg 选项。如果我在编译时使用 -pg 而在链接时不使用,我可以重现问题(即未定义 gmon* 调用的符号)。

来自gcc documentation

-pg

生成额外的代码来编写适合于 分析程序gprof。编译时必须使用此选项 你想要数据的源文件,你也必须在什么时候使用它 链接。

【讨论】:

  • 完美。谢谢!只是为了补充答案:在我的情况下,我使用的是旧的 GNU Make 并且不想修改 makefile,“-pg”标志通过(环境变量)CFLAGS(对于对象 (.o) 生成)和链接阶段的 LDFLAGS。
猜你喜欢
  • 1970-01-01
  • 2013-11-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-11-05
  • 1970-01-01
  • 2013-09-27
  • 2017-06-06
相关资源
最近更新 更多