为什么GCC编译的应用程序总是包含_mcount符号？

Question

库并不总是包含 _mcount 符号，但应用程序包含（您可以使用 gobjdump 或 nm 实用程序验证这一点）。我读过 _mcount 用于实现分析，但即使禁用分析并启用优化（-O2），该符号仍然存在。它还有其他额外的用途吗？

更新：我使用的是 Solaris，所以这是 Solaris 链接器与 GCC 的结合，我不确定这是否有区别。 GCC 版本是 4.2.2。即使我编译一个仅包含代码 int main() { return 0; 的文件，也会发生这种情况。 } 没有链接库。

Update2：我输入：

$ g++ -O2 mytest.cpp
$ nm a.out | grep _mcount
[65]    | 134547444|       1|FUNC |GLOB |0    |11     |_mcount

并且 g++ 没有给任何东西起别名。另外，我尝试用sun CC编译器编译，没有这个问题。我也尝试更新GCC，符号仍然存在于4.4.1中。

Answer 1

嗯。奇怪的是，在我的机器（ubuntu 9.10）上这不会发生。

为了进行测试，我刚刚编译了一个小hello-word：

#include <stdio.h>

int main (int argc, char **args)
{
  printf ("hello world\n");
}

编译

gcc test.c

它没有 _mcount 符号。我检查过：

nm a.out | grep -i count

尝试一些编译器开关（-g、-pg 等），结果发现该符号仅在使用 -pg 编译应用程序时出现，在这种情况下，您在启用分析的情况下进行编译，因此 _mcount 符号有一个原因存在。

Answer 2

您是否正在链接启用了分析的库？这将引入 _mcount。

Answer 3

有关信息，

在我的 Linux 机器 (Archlinux x86)、GCC 4.4.2 上，在 a.out 上运行 nm 给出：

$ nm ./a.out 
08049594 d _DYNAMIC
08049680 d _GLOBAL_OFFSET_TABLE_
0804852c R _IO_stdin_used
         w _Jv_RegisterClasses
08049584 d __CTOR_END__
08049580 d __CTOR_LIST__
0804958c D __DTOR_END__
08049588 d __DTOR_LIST__
0804857c r __FRAME_END__
08049590 d __JCR_END__
08049590 d __JCR_LIST__
080496a0 A __bss_start
08049698 D __data_start
080484e0 t __do_global_ctors_aux
080483d0 t __do_global_dtors_aux
0804969c D __dso_handle
         w __gmon_start__
         U __gxx_personality_v0@@CXXABI_1.3
080484da T __i686.get_pc_thunk.bx
08049580 d __init_array_end
08049580 d __init_array_start
08048470 T __libc_csu_fini
08048480 T __libc_csu_init
         U __libc_start_main@@GLIBC_2.0
080496a0 A _edata
080496a8 A _end
0804850c T _fini
08048528 R _fp_hw
08048324 T _init
080483a0 T _start
080496a0 b completed.5829
08049698 W data_start
080496a4 b dtor_idx.5831
08048430 t frame_dummy
08048460 T main

并在a.out

$ ldd ./a.out 
linux-gate.so.1 =>  (0xb77b1000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb769b000)
    libm.so.6 => /lib/libm.so.6 (0xb7675000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7658000)
    libc.so.6 => /lib/libc.so.6 (0xb7511000)
    /lib/ld-linux.so.2 (0xb77b2000)

尝试通过在依赖库上运行 nm 来确定是否已使用分析支持构建了某个依赖库。正如 @Emerick 所说，这将引入 _mcount。

Answer 4

没有帮助，但也许提供了信息：

在全新安装 OpenSolaris 和 g++ 时，我看到了相同的结果。

在 OpenSolaris 上的 gcc/++ 手册页中，它指出调试信息的默认级别是“2”...但将其更改为 1 或 0 并不会消除 _mcount 符号。

如果我使用 cc-5.0 进行编译，则不存在 _mcount 符号。 （虽然使用 cc 进行编译，但 cc 只是 gcc 的别名/包装器）。

在 Ubuntu 和 Fedora 上，除非使用 -pg 选项进行编译，否则该符号不存在（在这种情况下，该符号是 mcount 而不是 _mcount）。