¿Por qué las aplicaciones compiladas por GCC siempre contienen el símbolo _mcount?

Question

Las bibliotecas no siempre contienen el símbolo _mcount, pero sí las aplicaciones (puede verificar esto con gobjdump o la utilidad nm). He leído que _mcount se usa para implementar el perfil, pero el símbolo está presente incluso cuando el perfil está deshabilitado y la optimización está habilitada (-O2). ¿Sirve para algún otro propósito adicional?

Actualización: Estoy en Solaris, este es el engarce de Solaris combinado con GCC, no estoy seguro de si eso hace la diferencia o no. La versión de GCC es 4.2.2. Esto sucede incluso si compilo un archivo que solo contiene el código int main() { return 0; } sin bibliotecas vinculadas.

Update2: I Tipo:

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

y G ++ no tiene un alias para nada. Además, traté de compilar con el compilador Sun CC, y no tiene este problema. También intenté actualizar GCC, el símbolo todavía existe en 4.4.1.

Answer 1

Hm. extraño, en mi máquina (ubuntu 9.10) esto no sucede.

Para una prueba que acaba de compilar una pequeña hola-palabra:

#include <stdio.h> 

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

compilado con

gcc test.c 

No tiene el símbolo _mcount. He hablado con: (. -g, -pg ect)

nm a.out | grep -i count 

Tratando algunos modificadores del compilador resulta que el símbolo sólo aparece si compila su aplicación con -pg, en este caso se compila con seguimiento permitido, por lo que el símbolo _mcount tiene una razón para existir.

Answer 2

¿Está vinculado con una biblioteca que tiene perfiles habilitados? Eso atraería _mcount.

Answer 3

Para obtener más información,

En mi máquina Linux (x86 Archlinux), GCC 4.4.2, corriendo nm en a.out da:

$ 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 

y funcionando en ldda.out da

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

Intente averiguar si una de las bibliotecas dependientes se ha creado con soporte de perfiles ejecutando nm en ellos. Como dijo @Emerick, esto generaría _mcount.

Answer 4

No helpeful, pero quizás informativo:

En una nueva instalación de OpenSolaris y g ++, veo los mismos resultados.

En la página del manual para gcc/++ en OpenSolaris, se observa que el nivel predeterminado de información de depuración es "2" ... pero cambiar eso a 1 o 0 no elimina el símbolo _mcount.

Si compilo con cc-5.0, el símbolo _mcount no está presente. (Aunque compilar con CC es como cc es solo un alias/envoltorio para gcc).

En Ubuntu y Fedora el símbolo no está presente a menos que se compile con la opción -pg (en cuyo caso el símbolo es mcount en lugar de _count).