Вопросы по динамическим библиотекам

Сообщение от niXman можешь пояснить более популярно чем в куче манов, что конкретно выполняет флаг -fPIC при либковке .so файла?

Флаг -fPIC - это компиляция позиционно-независимого кода. Только из таких кодов можно сделать динамическую библиотеку с разделяемыми кодами. Если компилировать модули без -fPIC и потом собрать *.so, то формально у тебя динамическая библиотека получится, но код будет не разделяемым. Для каждого процесса, использующего этот модуль, будет создаваться копия кодов. Флаг -fPIC нужен для компиляции из исходника в объектник, для линковки не нужен. "Нормальный" процесс выглядит так:

0

Сообщение от Evg Для каждого процесса, использующего этот модуль, будет создаваться копия кодов.

т.е. с этим флагом, если я загружу библиотеку в первом приложении при помощи dlopen(), то все последующие приложения при выполнении dlopen() фактически не будут загружать библиотеку заново? но как в таком случае будет происходить использование переменных в библиотеке? ведь первый процесс может установить некоторую переменную в одно значение, а второй в другое. как в таком случае разделать процессы?
и какое влияние на это оказывают флаги RTLD_GLOBAL и RTLD_LOCAL ?

0

Добавлено через 2 минуты

Сообщение от niXman .е. с этим флагом, если я загружу библиотеку в первом приложении при помощи dlopen(), то все последующие приложения при выполнении dlopen() фактически не будут загружать библиотеку заново? но как в таком случае будет происходить использование переменных в библиотеке? ведь первый процесс может установить некоторую переменную в одно значение, а второй в другое. как в таком случае разделать процессы? и какое влияние на это оказывают флаги RTLD_GLOBAL и RTLD_LOCAL ?

Вы смешиваете в одну кучу PIC и COW

0

Evg, в этом мане, в главе 3.4, написано такое:

Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, I choose -fPIC, because it always works.

т.е. если моя библиотека не превышает какого-то размера, то мне все же логичнее использовать влаг -fpic ?

Добавлено через 2 минуты

Сообщение от g_u_e_s_t COW

это что? ненашел таких опций компилятора/линкера.

0

Сообщение от niXman это что? ненашел таких опций компилятора/линкера.

это не опция) это Copy-on-Write. тобишь как только ваша программа испортит хоть байт данных в адресном пространстве библиотеки система выдаст вам индивидуальную копию этой страницы памяти. Собственно с PIC/Relocated code это никак не связанно

Там речь не о ограничениях на размер кода, а об аппаратных платформах (в основном антикварных) где PIC не возможен

0

Сообщение от niXman т.е. с этим флагом, если я загружу библиотеку в первом приложении при помощи dlopen(), то все последующие приложения при выполнении dlopen() фактически не будут загружать библиотеку заново? но как в таком случае будет происходить использование переменных в библиотеке? ведь первый процесс может установить некоторую переменную в одно значение, а второй в другое. как в таком случае разделать процессы?

Да. И не только через dlopen. По умолчанию любая программа линкуется с динамическими библиотеками. Если ты компиляешь hello world, то он слинкуется с динамической libc.so. В виртуальной памяти какждого процесса, использующего динамическую библиотеку, имеется как бы своя копия (загруженная по разным виртуальным адресам), но в физической памяти находится один экземпляр билиотеки, а виртуальная память каждого из процессов отмапирована на одну и ту же физическую.

Разделяемым является только код (исполняемые фрагменты) и read-only данные (последнее зависит от компилятора). Read-write данные, понятное дело, в каждом процессе имеют свою копию. Любая среднестатистическая библиотека содержит глобальных данных на порядки меньше, чем кода, а потому за счёт дублирования данных потери памяти не такие уж и большие.

Когда ты генерируешь код через -fPIC, то все обращения к глобальным переменным строятся по косвенности. Грубо говоря, в каждом процессе в начале процедуры формируется некое значение, а все обращения к глобальным переменным делаются косвенными - через специальную табличку (которая является данными), в которой прописаны адреса всех глобальных переменных. Такой подход обеспечивает то, что код (исполняемые фрагменты) не содержат настройки на абсолютные адреса, а потому может свободно разделяться между процессами (ибо везде он побайтно совпадает). А если *.so собирать из модулей, собранных без -fPIC'а, то в таком коде будут настройки на абсолютные адреса (которые в разных процессах могут не совпадать) и потому такой код нельзя сделать разделяемым

Сообщение от niXman и какое влияние на это оказывают флаги RTLD_GLOBAL и RTLD_LOCAL ?

Понятие global/local они разными в зависимости от контекста. Говоря о языке программирования, словом global называют переменную со статическим временем жизни (т.е. живёт всю программу), а local - переменную с автоматическим временем жизни (живёт внутри активации процедуры). Говоря о бинарном формате файла, global - означает метку, видимую из других модулей, а local - метку , не видимую из остальных модулей. Грубо говоря, global для бинарного формата соответствует global'у языка Си без модификатора static, а local бинарного формата - global'у языка Си с модификатором static

1

Добавлено через 3 часа 7 минут
Evg, скажи, а компилятор/линкер в .so файле не сохраняют версию компилятора/линкера/libc/libstdc++, которые использовались для линковки этой so`шки ?
каким-то образом эту информацию можно получить? или только предварительно сохранив?

0

Версия компилятора и линкера никак не должна отражаться в бинарнике. Но компилятор может в коде создавать специфическую метку. gcc-2.95, например, в каждом объектнике создавал метку с именем что-то типа ".gcc2_compiled". Более поздние версии gcc при генерации ассемблерного файла пишут строку что-то типа ".ident gcc: <версия>", а куда оно попадает дальше в объектном файле - с ходу не знаю. Наверняка и у линкера есть подобные подпольные приблуды. Но все они носят чисто отладочный характер - т.е. чтобы глазками на них посмотреть и не должны ни к чему обязывать. Хотя где-то в коде линкера под какую-то архитектуру я видел затычки, что при наличии метки ".gcc2_compiled" линкер понимал, что код сгенерил gcc и обходил какую-то ошибку компилятора.

Касаемо версии динамической библиотеки тут немного сложнее. В стандарте elf в заголовке секции можно вклеить так называемые dynamic tags - какие-то вопсомогательные фичи, которые используются при динамической загрузке файла (*.so или исполняемого). Часть этих тэгов является стандартной (т.е. их поведение в спецификации elf'а записано), а часть - implementation defined.

Всё, что с большими номерами - это implementation defined. Среди этого списка есть SONAME - так называемый идентификатор динамической библиотеки. Когда мы теперь линкуем бинарник с такой динамической библиотекой, то в бинарнике появляются тэги NEEDED, в которых записаны значения полей SONAME тех динамических библиотек, которые участвовали в линковке (но в бинарник, ясным образом, не вклеивались)

Таким образом, хотя бинарник и отвязан от динамических библиотек, но тем не менее имеются зацепки на предмет того, которая из версий нужна. Если я ничего не путаю, то поле NEEDED трактуется как имя файла (хотя формируется на основании поля SONAME).

Если посмотреть, какие из файлов присутсвуют в файловой системе (в каталогах /lib и /usr/lib), то можно увидеть 3 файла для glibc. В моём случае имеются:

Файл libc-2.11.1.so представляет собой сами коды библиотеки и под таким именем нигде не используется (ни при линковке, ни при динамической загрузке). Файл libc.so используется только при линковке. То, что он скрипт, это некая особенность именно glibc, но условно можно считать, что это символьная ссылка на libc.so.6 (но не libc-2.11.1.so). Файл для линковки содержит только имя (libc.so) без каких-бы то ни было номеров версий, потому как компилятор подаёт в линкер опцию -lc, дабы не привязываться ни к каким номерам версий. В момент исполнения загружается файл libc.so.6 на основании поля NEEDED.

Для чего нужна такая наносистема. Допустим, на машине установили более позднюю версию glibc, принципиально отличающуюся интерфейсами (и, стало быть, имеющие бинарную НЕсовместимость со старой glibc). При таком раскладе все свежескомпилированные программы должны настраиваться на новую версию glibc, однако старые бинарники должны работать со старой версией glibc, потому как с новой они не смогут работать. В этом случае файлы будут такими (новые и изменённые помечаю звёздочкой):


Таким образом при компиляции свежих программ будет использоваться файл libc-2.18.1.so через ссылку libc.so.7 и скрипт libc.so. В поле NEEDED у бинарника скопируется SONAME со значением libc.so.7, а потому на исполнении будет подцепляться libc.so.7 (который указывает на libc.2.18.1). А старые бинарники по прежнему при исполнении будут загружать старую lib.so.6

При таком объяснении на первый взгляд кажется, что схема из трёх файлов избыточная и достаточно двух. Т.е. казалось бы, что вполне достаточно иметь файлы (а не ссылки) libc.so.6 и libc.so.7. Но на самом деле эти указанные файлы олицетворяют собой версию интерфейса (а не библиотеки). Т.е. может выйти библиотека libc-2.11.5.so (т.е. изменение минорной цифры версии) или libc-2.13.1.so (изменение второй цифры версии, но при этом коды остаются бинарно совместимыми). В этом случае копируется файл libc-2.13.1.so и перенастраивается существующая ссылка libc.so.6, после чего старые программы начинают работать с новой библиотекой (потому что новая бинарно совместима со старой), а не со старой, как в предыдущем примере

Добавлено через 7 минут

Сообщение от niXman Evg, в этом мане, в главе 3.4, написано такое: т.е. если моя библиотека не превышает какого-то размера, то мне все же логичнее использовать влаг -fpic ?

Вчера забыл ответить на вопрос. Есть две опции -fpic и -fPIC. Для большинства архитектур они делают одно и то же. Но некоторые архитектуры позволяют "укороченные" варианты косвенного доступа. Что-то из разряда того, что если расстояние между сегментами кода и данных не превышает 64 килобайта, то вместо 32-битного относительного смещения можно использовать 16-битное, что может укоротить (и, соответсвенно, ускорить) исполнение кода. В этом случае можно использовать опцию -fpic (маленькие буквы олицетворяют укороченный вариант). Но если при дальнейшем формировании динамической библиотеки постфактум окажется, что в эти ограничения не уложились, то линкер выдаст ошибку. И надо будет пересобрать всё с опцией -fPIC (в этом случае всё будет работать без ограничений). Что-то из разряда того. Я точно знаю, что сия фича используется на sparc'е и дико подозреваю, что возможно использовать на i386.

Реальное убыстрение ты заметишь только тогда, когда есть обращение к глобальной переменной в цикле с большим количеством итераций. А при "обычном" доступе к глобалу вне цикла этого не почувствовать: т.е. ускорение в 2 такта для кода длиной в 10000 тактов - это экономия на спичках. Лучше пользуйся -fPIC'ом - меньше проблем будет

4

Evg, Спасибо, подробно и интересно.

Если я ничего не путаю, то поле NEEDED трактуется как имя файла (хотя формируется на основании поля SONAME).

Т.е. для каждой DT_NEEDED записи должна быть своя запись DT_SONAME?
Из прочитанного мной когда-то описания ELF-формата это не очевидно, но если это так, то зачем такой дубль?
И еще я бы все таки добавил, что возможность слинковать программу с конкретной версией библиотеки есть. В смысле DT_SONAME вполне может содержать и полную версию, или как вариант есть возможность подсунуть библиотеку не из /usr/lib через DT_RPATH (ключик rpath у линкера)

0

Сообщение от g_u_e_s_t Т.е. для каждой DT_NEEDED записи должна быть своя запись DT_SONAME?Из прочитанного мной когда-то описания ELF-формата это не очевидно, но если это так, то зачем такой дубль?

SONAME записывается динамической библиотеке. NEEDED, грубо говоря, записывается в исполняемом файле, требующем эту динамическую библиотеку. Т.е. одно и тоже пишется в двух разных местах, чтобы при их совместной загрузке понять, совместимы они, или нет

Сообщение от g_u_e_s_t И еще я бы все таки добавил, что возможность слинковать программу с конкретной версией библиотеки есть. В смысле DT_SONAME вполне может содержать и полную версию, или как вариант есть возможность подсунуть библиотеку не из /usr/lib через DT_RPATH (ключик rpath у линкера)

3 раза прочитал мысль но ничегоне понял. Никто не говорит про физическую невозможность слинковать что-то с чем-то. Способов совместить несовместимое - миллион. Только работать оно не будет. А вся эта магия с NEEDED и SONAME по большому счёту нужна только ради того, чтобы сразу же было понятно, что есть два несовместимых бинарника (напиример, a.out и libc.so). Чтобы это было понятно на этапе линковки или загрузки, а не на этапе исполнения, когда-то программа на ровном месте ломается и причины совершенно непонятны

1

SONAME записывается динамической библиотеке. NEEDED, грубо говоря, записывается в исполняемом файле, требующем эту динамическую библиотеку. Т.е. одно и тоже пишется в двух разных местах, чтобы при их совместной загрузке понять, совместимы они, или нет

А вы уверенны???
Это не совсем линукс но вполне честный ELF:
Т.е. записи типа DT_SONAME отсутсвуют как класс - кругом DN_NEEDED.
Система (это netbsd) при этом умеет ругаться на не ту версию .so.

Если я вас не так понял, то поясните пожалуйста подробнее, ну или ссылку (предпочтительнее) на первоисточник инфы.

Добавлено через 25 минут

Сообщение от Evg 3 раза прочитал мысль но ничегоне понял. Никто не говорит про физическую невозможность слинковать что-то с чем-то

B посте №22 вы, как мне показалось (возможно ошибочно) особо подчеркнули тот факт, что в SONAME не указанна конкретная версия требуемой библиотеки.
Совмещать, что-то с чем-то и не надо, а вот возможность линковать с конкретной версией бывает нужна.

А вся эта магия с NEEDED и SONAME по большому счёту нужна только ради того, чтобы сразу же было понятно, что есть два несовместимых бинарника (напиример, a.out и libc.so).

Я б сказал чуть иначе. Это не магия, а способ указания системе в лице ld.so мест где искать требуемые программе символы.

0

Сообщение от g_u_e_s_t А вы уверенны???

Уверен. По твоей строке у меня выдаётся портянка на несколько экранов. Если SONAME нет, то линкер в качестве этого SONAME использует имя файла. Оно нужно тогда, когда файл, например, называется libc-2.11.1.so, но при этом SONAME=libc.so.6

Сообщение от g_u_e_s_t ну или ссылку (предпочтительнее) на первоисточник инфы

Ссылку не знаю. Просто я работал с этим в своё время

Сообщение от g_u_e_s_t что в SONAME не указанна конкретная версия требуемой библиотеки

В SONAME можно писать что угодно. Но пишут обычно номер версии. Причём не версии библиотеки, а версии некоторого программного соглашения. Две разные версии библиотеки могут иметь один и тот же SONAME: они имеют один и тот же набор интерфейсов, просто реализованы по разному.

Как правило более поздня библиотека имеет более широкий набор интерфейсов, но бинарно совместим с более ранней библиотекой. В этом случае у них одинаковый SONAME. И типичный случай - это когда прямая совместимость (от ранней версии к поздней) есть, а обратной (от поздней версии к ранней) - нет. При таком раскладе можно бинарник скомпилировать с более поздней версией библиотеки, а потом попробовать запустить с более ранней. Такие случаи рулятся немного по другому - версии приклеиваются ещё и к меткам (именам функций или переменных). Выглядит оно типа того:

Запуском

можно увидеть длинную портянку. Детальный смысл портянки я не знаю. Но суть в следующем. Допустим, в printf внесли ещё како-нибудь спецификатор (какой-нибудь %y, например). В этом случае совместимость со старой версией остаётся - старые коды с новым printf'ом будут работать. Но вот новые коды со старым printf'ом могут и не работать, если они используют %y. В этом случае в новой версии библиотеки лепится символ printf и приклеивается в нему версия типа "@@GLIBC_2.0.1". В этоге если новый код, скомпиленный с новой библиотекой, запустить со старой, то динамический загрузчик выругается на несоответсвие версий. Но если новый код printf не использует, то со старой библиотекой он сможет работать. Реально используется немного не так, но для объяснения "на пальцах" сойдёт.

Добавлено через 36 секунд

Сообщение от g_u_e_s_t Я б сказал чуть иначе. Это не магия, а способ указания системе в лице ld.so мест где искать требуемые программе символы

Нет. ГДЕ искать - за это отвечает RPATH, а NEEDED отвечает за то, ЧТО искать

1

Честно говоря, вы меня совсем запутали...
Выше в посте 22 вы пишете:

SONAME записывается динамической библиотеке. NEEDED, грубо говоря, записывается в исполняемом файле, требующем эту динамическую библиотеку.

Я удивляюсь, и показываю вам систему где это вовсе не обязательно: SONAME ни в exe ни в .so не присутствует. (Или вы скажите что там ELF кривой и надо бежать писать багрепорт?)
Т.е. NEEDED без SONAME возможно и работает. А наоборот SONAME без NEEDED возможно?


опус про совместимость чего-то с чем-то поскипан

Нет. ГДЕ искать - за это отвечает RPATH, а NEEDED отвечает за то, ЧТО искать

Да верно, за исключением случаев когда в NEEDED/SONAME есть слэш, тогда RPATH, LD_LIBRARY_PATH и прочие должны игнорироваться.

0

NEEDED в момент загрузки говорит о том, какие библиотеки нужны (ибо как по другому понять, что требуется, к примеру libm.so). Список этих NEEDED формируется в момент линковки (линкеру явно задаются все библиотеки, с которыми вдальнейшем на исполнении должна линковаться программа). В качестве этих NEEDED пишется то, что записано в SONAME подаваемой библиотеки. Если SONAME нет, то прописывается имя файла подаваемой библиотеки

0

В качестве этих NEEDED пишется то, что записано в SONAME подаваемой библиотеки. Если SONAME нет, то прописывается имя файла подаваемой библиотеки

О теперь более-менее ясно)
А каким ключиком линкера задать желаемый SONAME при линковке свой .so'шки?
UP: сам нашел -soname как ни странно)

0

Сообщение от g_u_e_s_t UP: сам нашел -soname как ни странно)

Да, но реально, как правило ручками запускается компилятор, а он уже запускает линкер. Из-под gcc эта опция выглядит как "-Wl,-soname=qqq". Для контроля подаётся дополнительно -v и глазками наблюдается, что опция передалась линкеру

0

такой мануальчик нарыл: http://www.akkadia.org/drepper/dsohowto.pdf
очень много инфы по созданию .so

1

Что-то документ не скачивается. Может его приаттачить сюда?

0

Сообщение от Evg Может его приаттачить сюда?

легко

Вложения

dsohowto.pdf (749.3 Кб, 26 просмотров)

0

Уж очень специфичный документ. Начинающий его не осилит. Это скорее техническая спецификация, чем мануал по созданию динамических объектов

0