Warum enthalten Anwendungen, die von GCC kompiliert werden, immer das Symbol _mcount?

Question

Bibliotheken enthalten nicht immer das _mcount-Symbol, aber Anwendungen tun dies (Sie können dies mit gobjdump oder dem Dienstprogramm nm überprüfen). Ich habe gelesen, dass _mcount verwendet wird, um das Profiling zu implementieren, aber das Symbol ist vorhanden, auch wenn das Profiling deaktiviert und die Optimierung aktiviert ist (-O2). Dient es einem anderen zusätzlichen Zweck?

Update: Ich bin auf Solaris, also ist dies der Solaris-Linker in Kombination mit GCC, ich bin mir nicht sicher, ob das einen Unterschied macht oder nicht. Die GCC-Version ist 4.2.2. Dies geschieht auch, wenn ich eine Datei kompiliere, die nur den Code int main() { return 0; } ohne verknüpfte Bibliotheken enthält.

Update2: I:

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

Und g ++ ist nicht auf irgendetwas aliased. Außerdem habe ich versucht, mit dem Sun CC Compiler zu kompilieren, und dieses Problem besteht nicht. Ich habe auch versucht, GCC zu aktualisieren, Symbol existiert noch in 4.4.1.

Answer 1

Hm. komisch, auf meiner Maschine (ubuntu 9.10) passiert das nicht.

Für einen Test, den ich zusammengestellt nur ein kleines hallo-Wort:

#include <stdio.h> 

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

zusammengestellt mit

gcc test.c 

Es hat nicht das _mcount Symbol. Ich habe mit: (. -g, -pg ect)

nm a.out | grep -i count 

einige Compiler-Schalter Der Versuch, es stellt sich heraus, dass das Symbol erscheint nur, wenn Sie Ihre Anwendung mit -pg kompilieren, in diesem Fall, dass Sie mit einer Profilierung kompilieren aktiviert ist, Also hat das _mcount-Symbol einen Grund zu existieren.

Answer 2

Verknüpfen Sie mit einer Bibliothek, für die die Profilerstellung aktiviert ist? Das würde _mcount anziehen.

Answer 3

Informationen,

Auf meinem Linux-Box (Archlinux x86), GCC 4.4.2, läuft nm auf a.out gibt:

$ 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 

und läuft ldd auf a.out gibt

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

Versuchen Sie herauszufinden, ob eine der abhängigen Bibliotheken mit Unterstützung für Profilerstellung erstellt wurde, indem Sieausführenauf ihnen. Wie @Emerick sagte, würde dies in _mcount ziehen.

Answer 4

Nicht helpeful, aber vielleicht informativ:

Auf einer Neuinstallation von Opensolaris und g ++, sehe ich die gleichen Ergebnisse.

In der Manpage für gcc/++ auf OpenSolaris notiert die Standardstufe der Debuginformationen "2" ... aber das Ändern von 1 oder 0 beseitigt das _mcount-Symbol nicht.

Wenn ich mit cc-5.0 kompiliere, ist das Symbol _mcount nicht vorhanden. (Obwohl es mit cc kompiliert wird, ist cc nur ein Alias ​​/ Wrapper für gcc).

Auf Ubuntu und Fedora ist das Symbol nicht vorhanden, es sei denn mit der Option -pg kompiliert (in diesem Fall ist das Symbol mcount und nicht _mcount).