Нужно ли 32-битный код x86 специально PIC-компилировать для файлов общей библиотеки?

Question

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

Теперь я не сталкивался с ошибками при попытке загрузить файл .so, скомпилированный и связанный без опции -fpic GCC на 32-битных компьютерах с архитектурой x86, в то время как на 64-битных компьютерах с архитектурой x86 он не работает.

Случайные веб-сайты, которые я обнаружил, говорят, что мне не нужно -fpic на 32-битном, потому что код, скомпилированный без -fpic, работает по совпадению в соответствии с 32-битным ABI X86 также при использовании позиционно-независимым способом. Но я все же нашел программное обеспечение, которое поставляется с отдельными версиями библиотек в их 32-битных версиях: одно для PIC и одно для не PIC. Например, компилятор intel поставляется с libirc.a и libirc_pic.a, причем последний компилируется для позиционно-независимого режима (если кто-то хочет связать этот файл .a в файл .so).

Интересно, какая точная разница между использованием -fpic и его неиспользованием для 32-битного кода и почему некоторые пакеты, такие как компилятор intel, все еще поставляются с отдельными версиями библиотек?

Answer 1

Дело не в том, что не-PIC-код работает "по совпадению" на x86 (32-битном).Дело в том, что динамический компоновщик для x86 поддерживает необходимые «textrels», необходимые для его работы.Это приводит к очень высокой стоимости потребления памяти и времени запуска, поскольку в основном весь сегмент кода должен быть исправлен во время загрузки (и, таким образом, становится неразделимой памятью).

Динамические компоновщики утверждают, что не- Общие библиотеки PIC не могут поддерживаться в x86_64 из-за фундаментальных проблем в архитектуре (немедленное смещение адресов не может превышать 32-разрядного), но эту проблему можно легко решить, просто всегда загружая библиотеки в первые 4 ГБ виртуальныхадресное пространство.Конечно, код PIC очень дешев на x86_64 (PIC не снижает производительность, как на 32-разрядных x86), поэтому они, вероятно, правы, чтобы оставить его без поддержки и не дать дуракам создавать библиотеки не-PIC ...

Answer 2

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

Поскольку общие объекты обычно загружаютсяпо своему предпочтительному адресу они могут работать правильно.Но fPIC - хорошая идея для всего совместно используемого кода.

Я считаю, что причина нечастого использования двух версий библиотеки в том, что во многих дистрибутивах fPIC используется по умолчанию для всего кода.