Почему приложения, скомпилированные GCC, всегда содержат символ _mcount? - PullRequest
Новая
       35

Почему приложения, скомпилированные GCC, всегда содержат символ _mcount?

6 голосов
/ 08 января 2010

Библиотеки не всегда содержат символ _mcount, но приложения содержат его (вы можете проверить это с помощью gobjdump или утилиты nm). Я читал, что _mcount используется для реализации профилирования, но символ присутствует, даже если профилирование отключено и включена оптимизация (-O2). Это служит какой-то другой дополнительной цели?

Обновление: я на Solaris, так что это компоновщик Solaris в сочетании с GCC, я не уверен, если это имеет значение или нет. Версия GCC - 4.2.2. Это происходит, даже если я компилирую файл, который содержит только код int main() { return 0; } без связанных библиотек.

Обновление2: я печатаю: 

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

И g ++ ни к чему не привязан. Кроме того, я попытался скомпилировать с помощью компилятора Sun CC, и у него нет этой проблемы. Я также пытался обновить GCC, символ все еще существует в 4.4.1.

Ответы [ 4 ]

4 голосов
/ 08 января 2010

Hm. странно, на моей машине (ubuntu 9.10) такого не происходит.

Для теста я только что составил небольшое приветственное слово: 

#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 есть причина есть.

2 голосов
/ 08 января 2010

Связываете ли вы библиотеку с включенным профилированием? Это потянет в _mcount.

1 голос
/ 15 января 2010

Не полезно, но, возможно, информативно:

В новой установке OpenSolaris и g ++ я вижу те же результаты.

На странице руководства для gcc / ++ в OpenSolaris он отмечает, что уровень отладочной информации по умолчанию равен "2" ... но изменение этого значения на 1 или 0 не устраняет символ _mcount.

Если я компилирую с cc-5.0, символ _mcount отсутствует. (хотя при компиляции с помощью cc он выглядит как псевдоним / оболочка для gcc).

В Ubuntu и Fedora символ отсутствует, если только он не компилируется с опцией -pg (в этом случае символом является mcount, а не _mcount).

1 голос
/ 11 января 2010

Для информации

На моем компьютере с Linux (Archlinux x86), GCC 4.4.2, при запуске nm на a.out выдается: 

$ 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

и работает ldd на 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.

...