Исполняемые файлы по сравнению с Общими объектами
Я заметил что-то при выполнении find /bin -exec file {} \; :
file управляйте сообщают некоторые записи в /bin shared objects , в то время как другие как executables . Например,
/bin/ntfsck:
ELF 64-разрядный общий объект LSB, x86-64, версия 1 (SYSV),
динамично связанный (совместно использованное использование освобождает), для GNU/Linux 2.6.24, BuildID[sha1]=312d93fd0d8653e7236a61db2e67b93c63225a00, разделенного
Тот же отчет для gawk
/usr/bin/gawk:
ELF 64-разрядный общий объект LSB, x86-64, версия 1 (SYSV),
динамично связанный (совместно использованное использование освобождает), для GNU/Linux 2.6.24,
BuildID[sha1]=76bb13aac7e212164bd6e0d7b8a5d92db44543c9, разделенный
По контрасту file для /bin/echo :
/bin/echo:
ELF 64-разрядный исполняемый файл LSB, x86-64, версия 1 (SYSV),
динамично связанный (совместно использованное использование освобождает), для GNU/Linux 2.6.24,
BuildID[sha1]=193e75fc13e9c4599e772b8d79125a5934cf601c, разделенный
По существу я хочу знать то, что является различием между executable файлы и shared object файлы.
2 ответа
Tl; доктор
нет никакого различия кроме того, что скомпилированный исполняемый файл мог бы быть связан против общего объекта, но не против исполняемого файла.
<час>В целом, существует два способа скомпилировать <глоток> 1 исполняемый файл:
- Используя статическое подключение: внешние библиотеки, включенные в исходный код, компилируются, и скомпилированная библиотека (или объект в перспективе компоновщика) добавляется к самому исполняемому файлу;
- Используя динамическое подключение: внешние библиотеки, включенные в исходный код, компилируются, но ссылка к скомпилированной библиотеке (или объект в перспективе компоновщика) добавляется к исполняемому файлу (и скомпилированные библиотеки / объекты загружаются компоновщиком во времени выполнения в случае необходимости);
существуют преимущества / недостатки в использовании каждого из этих методов, но это не точка вопроса;
-
/bin/ntfsckи/usr/bin/gawkобщие объекты: это означает, что исполняемый файл мог бы быть скомпилирован и затем связан против них для использования их технических возможностей; -
/bin/echoисполняемый файл: это означает, что исполняемый файл мог бы не быть скомпилированным и затем связанным против него для использования его технических возможностей;
Так /bin/ntfsck и /usr/bin/gawk технически скомпилированные библиотеки (или объекты в перспективе компоновщика), но, поскольку можно иметь, предвидел, ничто не препятствует тому, чтобы общий объект был выполнен как исполняемый файл.
На ноте стороны, заметьте также что file отчеты (для каждого из них):
динамично связанный (совместно использованное использование освобождает)
Это означает, что каждый из них динамично связан с (и вероятно использует), другие общие объекты также.
<час>1. "Скомпилируйте" предназначенный в ее более широком принятом значении слова, которое включает предварительную обработку, компиляцию и соединение.
Другое различие - то, что исполняемые файлы имеют определенное смещение адреса точки входа, т.е. 0x08048000 для i386, 0x00400000 для x86 и 0x00010000 для руки.
файл общего объекта А может быть библиотекой, но также и исполняемым файлом. Будучи исполняемым файлом, нет такого смещения. исполняемый файл общего объекта , так сказать, является позиционным независимым исполняемым файлом (PIE) с помощью рандомизации расположения адресного пространства (ASLR). Таким образом, при рассмотрении его/proc/pid/maps файла, Вы заметите, что местоположение загруженных сегментов варьируется по каждому выполнению в отличие от стандартных исполняемых файлов.
идея позади этой функции состоит в том, чтобы добавить безопасность к исполняемым файлам путем препятствия взломщикам от выполнения, ориентированного на возврат на программные нападения. Многие специалисты по обслуживанию решили создать пакеты с КРУГОМ, включенным как значение по умолчанию, например, начиная с Fedora 23 или с Ubuntu 17.10.