При динамическом линковании динамический загрузчик просматривает все объектные файлы для определений или только те, которые указаны в исполняемом файле? - PullRequest
0 голосов
/ 09 мая 2019

Так что я пытаюсь обернуть голову вокруг статического и динамического связывания.Есть много ресурсов на SO и в Интернете.Я думаю, что в значительной степени понимаю, но есть еще одна вещь, которая, кажется, беспокоит меня.Также, пожалуйста, исправьте меня, если мое общее понимание неверно.

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

С другой стороны, динамическое связывание - вот что меня больше удивляет: я понимаю, чтопри динамическом связывании заглушки в объектном коде, которые ссылаются на еще не разрешенные имена, будут оставаться заглушками до времени выполнения.

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

Итак, часть, которую я пропускаю, такова: где выглядит динамический загрузчик ОС - выглядит ли онв таблицах символов для всех объектных файлов в каталоге системных библиотек?Или он выглядит только в объектных файлах, указанных где-то в исполняемом файле приложения?Это причина, почему во время компиляции мы должны указать все динамические зависимости нашей программы?Кроме того, действительно ли динамические библиотеки также предоставляют таблицу символов?

Ответы [ 2 ]

1 голос
/ 09 мая 2019

Итак, часть, которую я пропускаю, такова: где выглядит динамический загрузчик ОС - ищет ли он в таблицах символов все объектные файлы в каталоге системных библиотек?

Нет динамического компоновщика, о котором я знаю.

Или он выглядит только в объектных файлах, указанных где-то в исполняемом файле приложения?

Ниточно так же, либо.

Детали различаются, но обычно динамический компоновщик ищет конкретные общие библиотеки по имени в различных каталогах.Поиск по каталогам может быть встроен в компоновщик, указанный операционной системой, указанный в объекте, который связан, или их комбинацию.Компоновщик (обычно) не проверяет таблицы символов библиотек до после , он находит их по имени и выбирает их для связывания.

По этой причине во время компиляции мы должныуказать все динамические зависимости нашей программы?

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

Кроме того, действительно ли динамические библиотеки также предоставляют таблицу символов?

Да.Динамические библиотеки имеют свои собственные таблицы символов, потому что

  1. Динамический компоновщик использует их для своей работы, а
  2. Динамические библиотеки могут иметь свои собственные требования динамического связывания, которые не обязательно отражаются восновные программы.
0 голосов
/ 09 мая 2019

При обычном использовании «динамическое связывание» выполняется загрузчиком. «Статическое связывание» выполняется компоновщиком.

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

С другой стороны, динамическое связывание - вот что меня удивляет: я понимаю, что при динамическом связывании заглушки в объектном коде, которые ссылаются на еще не разрешенные имена, будут оставаться заглушками до времени выполнения

Это не [обычно] правильно. Компоновщик найдет разделяемую библиотеку, в которой существует символ. Исполняемый файл будет иметь инструкцию найти символ в этой общей библиотеке. Линкеры, как правило, рвут, если не могут найти все символы, которые необходимо разрешить.

Итак, часть, которую я пропускаю, такова: где выглядит динамический загрузчик ОС - он ищет в таблицах символов все объектные файлы в каталоге системных библиотек?

Это системный вопрос. В хорошо спроектированных операционных системах общие библиотеки назначаются системным менеджером. Загрузчик использует библиотеку, указанную системой. Плохо спроектированные системы часто используют какой-то путь поиска для поиска разделяемых библиотек (что создало огромную дыру в безопасности).

...