Why do applications compiled by GCC always contain the _mcount character?

Question

Libraries do not always contain the _mcount character, but applications (you can check this with gobjdump or nm utility). I read that _mcount is used to implement profiling, but the symbol is present even when profiling is disabled and optimization is enabled (-O2). Does it provide other additional goals?

Update: I'm on Solaris, so this is the Solaris linker in conjunction with GCC, I'm not sure if it matters or not. The GCC version is 4.2.2. This happens even if I compile a file containing only int main() { return 0; } code int main() { return 0; } int main() { return 0; } without binding libraries.

Update2: I type:

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

And g ++ is not imposed on anyone. In addition, I tried compiling with the Sun CC compiler, and it does not have this problem. I also tried updating GCC, the symbol still exists in 4.4.1.

Answer 1

Hm. strange, on my machine (ubuntu 9.10) this does not happen.

For the test, I just compiled a small greeting word:

 #include <stdio.h> int main (int argc, char **args) { printf ("hello world\n"); } 

compiled with

 gcc test.c 

He did not have a _mcount character. I checked:

 nm a.out | grep -i count 

An attempt by some compilers (-g, -pg ect.) Turns out that the symbol appears only if you compile the application with -pg. In this case, you are compiling with profiling enabled, so the _mcount character has a reason to exist.

Answer 2

Are you linking to the library where profiling is enabled? This will pull _mcount .

Answer 3

For information

In my Linux box (Archlinux x86), GCC 4.4.2, nm on a.out works, it gives:

 $ 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 

and running ldd on a.out gives

 $ 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) 

Try to find out if one of the dependent libraries with profiling support was built by running nm on them. As Emerick said, it will pull _mcount .

Answer 4

Not serious, but perhaps informative:

With a new installation of OpenSolaris and g ++, I see the same results.

The gcc / ++ man page on OpenSolaris notes that the default debugging level is "2" ... but changing this value to 1 or 0 does not eliminate the _mcount character.

If I compile with cc-5.0, the _mcount character is missing. (although compiling with cc is like cc, it's just an alias / wrapper for gcc).

In Ubuntu and Fedora, the character is missing if the -pg option is not compiled (in this case the character is mcount, not _mcount).