TextRel: различия между версиями
(Import from freesource.info) |
Нет описания правки |
||
Строка 24: | Строка 24: | ||
текстовый сегмент проще, чем недоступный.</pre> | текстовый сегмент проще, чем недоступный.</pre> | ||
''[https://lists.altlinux.org/pipermail/devel/2008-January/068210.html ldv@ в devel@]'' | ''[https://lists.altlinux.org/pipermail/devel/2008-January/068210.html ldv@ в devel@]'' | ||
Если вы собираете пакет, содержащий лишь разделяемые | |||
библиотеки, то для решения проблемы TEXTREL, как правило, | |||
достаточно применить выражение %add_optflags %optflags_shared | |||
''ldv@ в devel@'' | |||
=== Ссылки === | === Ссылки === |
Текущая версия от 13:14, 24 февраля 2009
Разделяемые библиотеки и 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 кода, написанного на ассемблере.
TEXTREL - это дакая гадость, которая делает текстовый сегмент не совсем текстовым; фактически dynamic linker вынужден патчить сам текстовый сегмент, см. dsohowto; в результате атаковать доступный на запись текстовый сегмент проще, чем недоступный.
Если вы собираете пакет, содержащий лишь разделяемые библиотеки, то для решения проблемы TEXTREL, как правило, достаточно применить выражение %add_optflags %optflags_shared
ldv@ в devel@