Dlaczego aplikacje skompilowane przez GCC zawsze zawierają symbol _mcount?

Question

Biblioteki nie zawsze zawierają symbol _mcount, ale aplikacje to robią (możesz to sprawdzić za pomocą programu gobjdump lub narzędzia nm). Czytałem, że _mcount służy do implementacji profilowania, ale symbol jest obecny nawet wtedy, gdy profilowanie jest wyłączone i włączona jest optymalizacja (-O2). Czy służy on innym celom dodatkowym?

Aktualizacja: Jestem na Solarisie, więc jest to linker Solaris połączony z GCC, nie jestem pewien, czy to robi różnicę czy nie. Wersja GCC to 4.2.2. Zdarza się to, nawet jeśli skompiluję plik, który zawiera tylko kod int main() { return 0; } bez powiązanych bibliotek.

Update2: I typ:

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

I g ++ nie jest aliasem do niczego. Próbowałem także kompilacji z kompilatorem CC, i nie ma tego problemu. Próbowałem również aktualizacji GCC, symbol nadal istnieje w 4.4.1.

Answer 1

Hm. dziwne, na moim komputerze (ubuntu 9.10) tak się nie dzieje.

Do testu właśnie przygotował małą hello-słowo:

#include <stdio.h> 

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

skompilowany z

gcc test.c 

Nie ma symbol _mcount. Sprawdziłem: (. -g, -pg ect)

nm a.out | grep -i count 

Próbuje Niektóre przełączniki kompilatora okazuje się, że symbol pojawia się tylko jeśli skompilować aplikację z -pg, w tym przypadku kompilowania z profilowaniem włączona, więc symbol _mount ma powód do istnienia.

Answer 2

Czy łączysz się z biblioteką z włączonym profilowaniem? To by przyciągnęło _mcount.

Answer 3

Aby uzyskać więcej informacji,

Na moim Linuksie (ArchLinux x86), GCC 4.4.2, działa nm na a.out daje:

$ 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 

i działa ldd na a.out daje

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

Spróbuj dowiedzieć się, czy jedna z zależnych bibliotek została zbudowana z obsługą profilowania, uruchamiając nm na nich. Jak powiedział @Emerick, to będzie ciągnąć _mcount.

Answer 4

Nie helpeful, ale być pouczające:

Na nową instalację OpenSolaris i g ++, widzę te same rezultaty.

Na stronie podręcznika dla gcc/++ na OpenSolaris zauważa on domyślny poziom informacji o debugowaniu to "2" ... ale zmiana tego na 1 lub 0 nie eliminuje symbolu _mcount.

Jeśli skompiluję z cc-5.0, symbol _mcount nie jest obecny. (chociaż kompilowanie z cc jest tak jak cc to tylko alias/opakowanie dla gcc).

W systemie Ubuntu i Fedorze symbol nie występuje, chyba że kompiluje się z opcją -pg (w tym przypadku symbolem jest mcount zamiast _mcount).