[devel] #12712 - nagios PL_perlio_mutex

[Alexey Tourbin]

On Sat, Sep 08, 2007 at 05:51:49PM +0400, Alex Myltsev wrote:
> On 9/8/07, Alexey Tourbin <at на altlinux.ru> wrote:
> > глобальныме переменные на самом деле бывают двух типов --
> > "D" и "B" (data и bss).  Различие между ними я не совсем понимаю.
> Тип B лежит в секции bss, область памяти при запуске программы
> заполняется нулями. Поэтому секцию bss не нужно класть на диск -- всё
> равно там нули.
> Тип D лежит в секции .data и чем-то там инициализируется, но не нулём.

На таком уровне кто угодно понимает. :) Я не понимаю как присходит
компоновка extern переменных и какой "тип" у них в результате получается.
И, в частности, стоит ли вешать B-символы на symbol versioning, и в
каких именно случаях.

> Если, например, написать:
> 
> int foo = 0;
> int bar = 1;
> 
> и собрать DSO, то и получится:
> 
> $ nm libdso.so | egrep '(foo|bar)'
> 0000000000200700 D bar
> 0000000000200708 B foo
> 
> А потому что в одном ноль, а в другом не ноль.
> Но это всё в манах написано, это неинтересно.

Кстати у gcc есть опция -fzero-initialized-in-bss, которая включена
по умолчанию.  Поэтому 'foo = 0' и оказывается в bss.

> > $ 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 нету.

Вот здесь у меня есть большие сомнения.  Почему же она "вообще не
грузится"?  Попробуй сделать другую библиотеку libdso без символа
foo и подсунуть её через LD_LIBRARY_PATH уже скомпилированному user.
user не загрузится.

В том-то вся и проблема с #12712.  Если бы символ "B PL_perlio_mutex"
был самодостаточен, то никакой ошибки не возникло бы.

Другими словами, каежется, существуют как бы полноценные B-определения и
неполноценные extern B-ссылки.  Научная теория блин.

> А если её всё-таки загрузить, то в библиотеке и в
> приложении всё равно будет общий foo, потому что секция bss вроде как
> общая на всё приложение.
> 
> > Замечу, что сам perl ссылается на PL_perlio_mutex через "U".
> А вот это-то и непонятно :). Почему, почему в данном случае эту ссылку
> не запихнули в bss?..

Вот-вот.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20070908/2845c504/attachment-0002.bin>