[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