mkevac Mar 15 2017 at 10:02

Position-independent code (PIC) в разделяемых библиотеках

16 min

22K

Badoo corporate blogSystem Programming*Compilers*C*Development for Linux*

Translation

+65

Comments 9

Halt Mar 15 2017 at 11:59

Все хорошо, только записи в PLT традиционно называют «трамплином» а не «батутом».

mkevac Mar 15 2017 at 15:28

Вы правы! Спасибо!

ser-mk Mar 16 2017 at 02:50

Получается для вызова ф-ций static из библиотеки, PLT не требуется, достаточно только GOT?

mkevac Mar 25 2017 at 00:13

Если функция из библиотеки вызывает static функцию из библиотеки, то даже GOT не нужен, на сколько я понимаю. Достаточно offset-а до функции, а он известен.

ser-mk Mar 29 2017 at 12:55

на x86 все-таки наверно нужен будет, иначе переменные тоже адресовались offset'ом

lumag Apr 14 2017 at 16:10

Переменные в другой секции лежат.

boov Jan 23 2018 at 09:57

Не могли бы подробнее пояснить, почему в таком случае не требуется got и plt. Я не вижу разницы между static и рассмотренной в статье функцией. Для call ведь по-прежнему требуется абсолютный адрес, а его без got в случае pic не получить.

boov Jan 25 2018 at 09:59

Отвечу сам же. Инструкция call использует относительный адрес, а не абсолютный, как я считал выше. В случае вызова static функции линкеру нет смысла делать релокацию, т.к. функция внутренняя и ее расположение известно по смещению. Если же функция не static, то линкер создаст для нее релокацию, причины лежат в LD_PRELOAD и в глобальном переопределении внешних символов динамическим линкером.

KivApple Dec 12 2018 at 09:50

Насчёт безопасности — есть же mprotect, чисто технически линкер может изменить права доступа к секции кода на более строгие после релокации. Что до производительности — позиционнонезависимый код получается чуть более медленным из-за дополнительных операций, так что долгоживущим процессам может быть таки выгоднее потупить на загрузке. Вот по памяти выигрыш получается, да, с другой стороны данных обычно на порядок больше, чем кода...