[devel] Re: ELFs in /usr/share

[Alexey Tourbin]

On Sun, Sep 18, 2005 at 03:23:46AM +0400, Dmitry V. Levin wrote:
> > А нужны более тонкие проверки, с reverse lookup'ом.  Надо попробовать
> > нарисовать все эти ER-диаграммы.  Но для этого нужно поставить пиратскую
> > винду, водрузить на неё пиратскую Rational Rose и т.п.
> 
> Зачем?  Если в сборочной среде правильно запущенный "ldd -r" выявляет
> undefined references, то этого зачастую достаточно.

Ну в идеале нужно промоделировать работу ldd -r на основе базы данных
пакетов, ELF'ов, символов и soname'ов.  Что полученный дамп отчасти
позволяет сделать.  Нужно ещё несколько таблиц и join'ов по составным
ключам.

> Тот факт, что какой-то ELF содержит символ, похожий на тот, который
> показывает "ldd -r" как undefined reference, ещё мало что даёт.

Да.  Возмём некий ELF.  У него есть, с одной стороны, список soname'ов,
которые он требует.

$ readelf -d /usr/bin/perl |grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libperl.so.5.8]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.1]
$

С другой стороны, у него есть список undefined symbols, которые по
смыслу должны разрешиться в эти soname'ы.

$ nm -D /usr/bin/perl |awk NF==2 |head
         U PL_do_undump
         U PL_op_mutex
         U PL_sigfpe_saved
         U PL_use_safe_putenv
         U Perl_atfork_lock
         U Perl_atfork_unlock
         U Perl_croak_nocontext
         U Perl_newXS
         w _Jv_RegisterClasses
         w __gmon_start__
$

Каждый символ может разрешиться в одном (в любом) из soname'ов.
Это называется декартовым произведением символов на soname'ы.
Такая таблица получается со стороны "requires".

Со стороны "provides" предоставляется более очевидная таблица,
тоже символов и sonme'ов, в которой просто перечислены все динамически 
символы "с адресом" из soname'ов.

Далее делается inner join этих двух таблиц, по составному ключу
символ+soname.  Требование к полученному результату: каждый символ
должен разрешиться в одном и только одном из soname'ов.  Ну ясно
наверное, о чем речь идет.  Это и есть строгая проверка, более строгая,
чем `ldd -r'.  Сюда даже не обязательно реляционную модель приплетать,
просто она помогает понять entity-relationship.

> А там как раз такой дизайн:
> $ ldd -r /lib/libthread_db.so.1 >/dev/null 

Это я отдельно посмотрю.  Получется, что символы могут предоставляться
не только soname'ами, но и бинарями.  Тогда нужно усложнять модель по
части "кто кого загружает".

> > Да нет, я просто пока понял, что если символов вообще нигде нет, то их
> > точно вообще нигде нет. :)  Я написал, что это слабая проверка, она
> > ничего не гарантирует, только обнаруживает вопиющие случаи...
> Скорее клинические. :)

Ну вот если сделать давилку для публичных библиотек, то что она скажет
по поводу 
tomboy  /usr/lib/tomboy/libtomboy.so    U       GTK_IS_SOURCE_VIEW
?

Пропустит, потому что это не публичная библиотека.  Тем не менее,
символа GTK_IS_SOURCE_VIEW нигде нет.  Такое нужно давить в первую
очередь.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20050918/e4bff0df/attachment-0001.bin>