Почему делают приложения, скомпилированные GCC всегда, содержат _mcount символ?
Библиотеки не всегда содержат _mcount символ, но приложения делают (можно проверить это с gobjdump или nm утилитой). Я считал, что _mcount используется для реализации профилирования, но символ присутствует, даже когда профилирование отключено, и оптимизации включают (-O2). Это служит некоторой другой дополнительной цели?
Обновление: Я нахожусь на Солярисе, таким образом, это - компоновщик Соляриса, объединенный с GCC, я не уверен, имеет ли это значение или нет. Версия GCC 4.2.2. Это происходит, даже если я компилирую файл, который только содержит код int main() { return 0; } без связанных библиотек.
Update2: Я ввожу:
$ g++ -O2 mytest.cpp
$ nm a.out | grep _mcount
[65] | 134547444| 1|FUNC |GLOB |0 |11 |_mcount
И g ++ не искажается ни к чему. Кроме того, я пытался компилировать с компилятором CC солнца, и он не имеет этой проблемы. Я также пытался обновить GCC, символ все еще существует в 4.4.1.
4 ответа
Вы подключаетесь к библиотеке, в которой включено профилирование? Это потянет за собой _mcount .
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 ECT). Оказывается, что символ появляется только в том случае, если вы компилируете ваше приложение с помощью -PG, в этом случае вы компилируете с включенным профилированием, поэтому символ _Mcount имеет причину существовать.
Для информации,
На моем Linux box (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.
Не помогает, но, возможно, информативно:
на свежей установке opensolaris и g ++, я вижу те же результаты.
На странице человека для GCC / ++ на opensolaris он отмечает уровень отладки по умолчанию информацию о отладке - это «2» ... но изменение того, что на 1 или 0 не устраняет символ _Mcount.
Если я компилируюсь с CC-5.0 символ _mcount отсутствует. (Хотя компиляция с CC так как CC является просто псевдоним / оберткой для GCC).
На Ubuntu и Fedora символ не присутствует, если только не составление опции -pg (в этом случае символ mcount, а не _mcount).