7.2. Конструкция библиотеки динамической компоновки

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

Более того, ряд служебных полей содержат и результат размещения исполняемых файлов, имеющих обычно расширение EXE. В общем случае и объектные файлы, и исполняемые файлы имеют стандартизованный формат, описанный соответствующими документами. В связи с широким распространением параллельного программирования и широкого использования уже десятки лет библиотек динамической компоновки или их аналогов, сложились универсальные форматы, охватывающие как объектные, так и исполняемые файлы. Заметим, что указанные библиотеки также по существу оказываются исполняемыми, но не независимо исполняемыми, а специальной формой общей частью исполняемых программ. Поэтому они также охватываются указанными форматами.

Для двух основных операционных систем стандартными форматами исполняемых файлов являются соответственно PE и ELF, получившие позже детализацию согласно используемой разрядности системы как PE32, ELF32, PE64 и ELF64. Объектные файлы для Windows зависят в конечном счете от системы разработки и еще в разработках 10–15-летней давности могли иметь старый формат, унаследованный от прежних операционных систем MS, но к настоящему моменту произошел переход полностью на формат PE.

В исполняемых файлах должна присутствовать информация, задаваемая соответствующими полями стандартных структур этих файлов. Она предоставляет вне этих файлов информацию об определенных в файле внешних именах, доступных для использования другими файлами, в частности непосредственно исполняемыми программами, а также информацию об именах в других исполняемых объектах, которые необходимы для дальнейшей работы. Первая категория имен составляет так называемый экспорт (экспортируемые имена), вторая – импорт. Более образно, первые имена как бы соотносятся с указанием «берите для использования», а вторые – «нужно взять от других». В программной информации эти категории задаются служебными словами EXPORT и IMPORT.

Рассмотрим принципиальный вопрос, на каком этапе и в каком месте указывается информация о типе имени в изложенном выше смысле (экспорт или импорт). В общем случае имена, используемые внутри модуля, не обязательно должны быть одного из указанных типов. Если имя используется только внутри модуля, то оно является локальным и за пределами модуля не нужно, в частности может, если это не нужно для использования отладчика, полностью отсутствовать в объектном файле. Имя может быть нужно и вне объектного файла, но только для этапа явной компоновки, когда из нескольких объектных файлов делается один объединенный объектный или исполняемый для динамической компоновки. В этом случае имя имеет атрибут EXTERN (внешнее) или глобальное (только для других явно компонуемых модулей), но не быть ни экспортируемым, ни импортируемым.

Набор теоретических возможностей задания характеристики экспорта или импорта включает три варианта:

1) задание специальными директивами внутри исходного текста программы;

2) включение специальными утилитами в объектные файлы после их обычного создания;

3) указание специальными опциями компоновщика;

4) указание в специальном файле для компоновщика, которому опцией указывают на необходимость использования такого файла.

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

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

Для изучения содержимого разделяемых библиотек в Windows служит многофункциональная утилита DUMPBIN.EXE из комплекта средств разработки Microsoft.

В частности запрос вывода экспортируемых имен на экран с помощью DUMPBIN будет иметь вид

DUMPBIN –export имябиблиотеки

а вывод импортируемых имен из исполняемого файла достигается вызовом

DUMPBIN –import имяEXEфайла

Для просмотра структурного содержимого исполняемых файлов Linux можно использовать инструментальную оболочку Midnight-Commander, непосредственным указанием на просмотр служит нажатие клавиши F3, которая по умолчанию обеспечивает просмотр через использование фильтра, зависящего от реального типа файла, который по мере возможности просмотрщик определяет автоматически. Экспортируемые имена обозначаются при этом символом T, а импортируемые – симво- лом U во второй колонке. Переключение режима просмотра от фильтруемого к непосредственному и обратно выполняется нажатием клавиши F8 в режиме просмотра.