[devel] #12712 - nagios PL_perlio_mutex
Alex Myltsev
=?iso-8859-1?q?avm_=CE=C1_altlinux=2Eru?=
Сб Сен 8 17:51:49 MSD 2007
On 9/8/07, Alexey Tourbin <at на altlinux.ru> wrote:
> глобальныме переменные на самом деле бывают двух типов --
> "D" и "B" (data и bss). Различие между ними я не совсем понимаю.
Тип B лежит в секции bss, область памяти при запуске программы
заполняется нулями. Поэтому секцию bss не нужно класть на диск -- всё
равно там нули.
Тип D лежит в секции .data и чем-то там инициализируется, но не нулём.
Если, например, написать:
int foo = 0;
int bar = 1;
и собрать DSO, то и получится:
$ nm libdso.so | egrep '(foo|bar)'
0000000000200700 D bar
0000000000200708 B foo
А потому что в одном ноль, а в другом не ноль.
Но это всё в манах написано, это неинтересно.
> $ grep PL_perlio_mutex sym
> nginx /usr/sbin/nginx B PL_perlio_mutex
> perl-base /usr/bin/perl5.8.8 U PL_perlio_mutex
> perl-base /usr/lib/libperl.so.5.8.8 B PL_perlio_mutex
>
> Другими словами, nagios и nginx как бы "ссылаются" на переменную типа
> "B" в libperl.so.5.8, но эта ссылка почему-то имеет тип "B", а не "U".
Провёл эксперимент. Сделал к вышеупомянутой библиотеке клиента:
$ cat user.c
#include <stdio.h>
extern int foo;
void main()
{ printf("%x\n", &foo; }
$ gcc -c user.c
$ nm user.o | grep foo
U foo
$
Пока всё нормально. Но вот
$ gcc -L. user.o -o user -ldso
$ nm user | grep foo
0000000000600a20 B foo
Похоже, при линковке ld заметил, что foo всё равно в bss, и можно его
и здесь запихнуть в bss. Замечательно, что при запуске ./user
библиотека libdso вообще не грузится: неопределённых символов из неё
в ./user нету. А если её всё-таки загрузить, то в библиотеке и в
приложении всё равно будет общий foo, потому что секция bss вроде как
общая на всё приложение.
> Замечу, что сам perl ссылается на PL_perlio_mutex через "U".
А вот это-то и непонятно :). Почему, почему в данном случае эту ссылку
не запихнули в bss?..
Подробная информация о списке рассылки Devel