Будет ли библиотека динамической компоновки должна быть загружена в RAM

Вы правы, если dlopenникогда не вызывается, целевая библиотека никогда не загружается в (память процесса ).

Определение необходимых библиотек без чтения исходного кода похоже на вариант проблемы остановки. Вы можете использовать некоторую эвристику :, если программа не ссылается на libdl, то она не может использовать dlopen; если это так, то вы можете использоватьstrace(см. Как узнать, какие исполняемые файлы динамических библиотек загружаются при запуске?)или попытаться выяснить аргументы dlopenс помощью статического анализа. Но программа могла включать libdlнапрямую (либо через статическую компоновку,или путем построения кода ); а поскольку динамический компоновщик не волшебство, ничто не мешает программе -реализовать его самостоятельно, так что вы не можете быть абсолютно уверенными, что вы поймали все необходимые библиотеки, используя эти эвристики. Возможно, есть программы, которые понимают, что их отслеживают, и пропускают загрузку библиотеки -...

Единственный надежный способ составить список всех необходимых библиотек — прочитать исходный код.

As we know, any executable file, which is running, is loaded into RAM.

Неправильно!

исполняемый файл отображается в виртуальном адресном пространстве процессов, выполняющих его, с помощью виртуальной памяти подсистемы ядра. Физическая оперативная память управляется только ядром. ПрочтитеОперационные системы :Three Easy Pieces , чтобы узнать больше.

Не весь сегмент кода этого исполняемого файла получает страницы(не загружается! )в ОЗУ. В частности, большая часть кода, которая никогда не используется (, например. потому что он содержит какую-то большую функцию, которая никогда не вызывается ), не попадет в оперативную память. Читайте о подкачке и страничном кэше .

Иногда физической памяти недостаточно для удобной работы со всеми необходимыми страницами. В этой ситуации вы наблюдаете биение .

динамический компоновщик (см. ld -linux (8))а также dlopen (3)использует mmap (2)для отображения в памяти некоторых сегментов из общей библиотеки. Таким образом, он не загружает весь сегмент кода плагина в оперативную память. Прочтите также статью ДреппераHow To Write Shared Libraries .

when we execute it and type always a, the dlopen will never be called, so mysofile will never be linked, which means that mysofile will never be loaded into RAM.

Нет абсолютно никакого способа вообще предсказать, какие общие библиотеки будут использоваться в будущем иdlopen-ред. Подумайте о следующих двух сценариях:

• продолжительная программа (возможно, ваш браузер )запрашивает у пользователя некоторую общую библиотеку (возможно, загружает ее из сети ), а затем dlopenее.

• процесс генерирует некоторый код C во временном файле /tmp/emittedcode.c, скомпилируйте (путем forkвключения соответствующего процесса, запускающего некоторыйgcc -O -Wall -fPIC /tmp/emittedcode.c -shared -o /tmp/emittedcode.so)этот файл во временный подключаемый модуль /tmp/emittedcode.soиdlopen-который временный плагин (конечно позжеdlsym-вписывая туда соответствующие символы ).

Мне очень нравится второй подход.Заметьте, что компиляция в C является устоявшейся привычкой. А текущие компиляторы достаточно быстры, чтобы сделать это даже в некотором взаимодействии REPL.

Кстати, на рабочем столе Linux процесс можетdlopenиметь много общих объектов , т. е. подключаемых модулей (, по крайней мере, сотни тысяч, а возможно, и миллионы ). См. мойmanydl.cпример (, который генерирует «случайный» код C во временных файлах и повторяет ).

ПС. Помните также о Проблеме Остановки , связанной с теоретической невозможностью предсказать все будущиеdlopen-ed пути.