TextRel

Материал из ALT Linux Wiki
Версия от 19:04, 28 июля 2008; MichaelShigorin (обсуждение | вклад) (Import from freesource.info)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Freesource-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была перемещена с freesource.info.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.


Разделяемые библиотеки и text relocations

Начну с вольного перевода нескольких фрагментов из статьи "How To Write Shared Libraries" (Ulrich Drepper, http://people.redhat.com/drepper/dsohowto.pdf, 2003, версия 1.2).

"Самое главное - всегда использовать параметры -fpic либо -fPIC при порождении кода, который в конечном итоге попадёт в DSO. Эта рекомендация применима в равной степени как к коду, так и к данным. Код, который не был скомпилирован таким образом, будет содержать text relocations. Этому нет оправдания. Text relocations требуют от динамического компоновщика (dynamic linker) дополнительной работы. Аргументы, базирующиеся на утверждении, что код не является разделяемым потому, что другие процессы не используют этот DSO, не верны. В таком случае вообще нет смысла использовать DSO; соответствующий код следует просто собирать в составе приложения."

"Результат любого перемещения (relocation) будет сохранен в виде ссылки где-то в DSO. В нормальной ситуации это место будет расположено в сегменте данных. В случае некорректно порождённого пользователем, компилятором или компоновщиком кода перемещения могут затрагивать сегменты кода и read-only данных. Динамический компоновщик в состоянии обработать корректно эту ситуацию только в случае, если DSO, в соответствии со спецификацией формата ELF, содержит пометку DT_TEXTREL в его динамической секции (dynamic section). В результате, к сожалению, изменённая страница памяти больше не будет разделяемой, т.е. не сможет быть использована другими процессами. Сам процесс text relocation также довольно длительный ввиду того, что ядро производит дополнительные изменения в структурах хранения информации по управлению памятью. И, наконец, код и данные, которые могли бы быть размещены в read-only памяти, оказываются в обычной памяти, доступной для случайного изменения вследствие сбоя в программе."

Если вы собираете пакет, содержащий лишь разделяемые библиотеки, то для решения проблемы TEXTREL, как правило, достаточно применить выражение %add_optflags %optflags_shared

Если в пакете присутствуют как DSO, так и обычные исполняемые приложения, то проблему TEXTREL, как правило, можно решить путём корректировки CFLAGS в makefile'ах.

Ситуация значительно осложняется в случае, если проблема TEXTREL вызвана наличием не-PIC кода, написанного на ассемблере.

ldv@ в devel@

TEXTREL - это дакая гадость, которая делает текстовый сегмент не совсем
текстовым; фактически dynamic linker вынужден патчить сам текстовый
сегмент, см. dsohowto; в результате атаковать доступный на запись
текстовый сегмент проще, чем недоступный.

ldv@ в devel@

Ссылки