Каковы настоящие требования ELF TLS ABI для каждой архитектуры процессора?

Документ Ульриха Дреппера о локальном хранилище потоков описывает TLS ABI для нескольких различных архитектур ЦП, но Я считаю его недостаточным в качестве основы для реализации TLS по двум причинам:

  1. В нем отсутствует ряд важных арок, таких как ARM, MIPS и т. д. (но включено несколько совершенно неуместных, таких как Itanium).
  2. Что еще более важно, он смешивает множество деталей реализации с ABI, так что трудно сказать, какие свойства необходимы для взаимодействия, а какие являются просто аспектами его реализации.

Например, единственными фактическими требованиями к ABI для i386 являются:

  • %gs:0 указывает на указатель на самого себя.
  • Сегмент TLS основного исполняемого файла, если он есть, должен располагаться по фиксированному (по компоновщику, отрицательному) смещению от этого адреса.
  • Все остальные сегменты TLS для первоначально загруженных библиотек должны иметь постоянные во время выполнения (т. е. одинаковые для каждого потока, но не обязательно одинаковые для разных запусков программы) смещения относительно этого адреса (и динамический компоновщик должен иметь возможность заполнять перемещения с помощью эти смещения).
  • Функции ___tls_get_addr и __tls_get_addr должны существовать с правильной семантикой для поиска произвольных сегментов TLS.

В частности, существование или расположение DTV не является частью ABI, равно как и порядок/расположение сегментов TLS, кроме основной программы.

Кажется, что любая арка, использующая «TLS вариант II», имеет примерно указанные выше требования к ABI. Но я вообще не очень хорошо понимаю требования «TLS варианта I», и из чтения источников (в uClibc и glibc) кажется, что может быть даже несколько вариантов «варианта I».

Есть ли какие-либо лучшие документы, на которые мне следует обратить внимание, или кто-нибудь, знакомый с работой TLS, может объяснить мне требования ABI?


person R.. GitHub STOP HELPING ICE    schedule 14.10.2012    source источник
comment
Извините, если я спрашиваю очевидное, но проверяли ли вы поддержку GCC TLS? Например, в списке рассылки gcc-patches есть ветка, начинающаяся 1 июня этого года, о добавлении поддержки MIPS16 TLS (marc.info/?l=gcc-patches&m=132586147826602). Создатели компиляторов кажутся гораздо более формальными в таких вещах, чем разработчики библиотеки C; у них может быть лучшая формальная документация.   -  person Nominal Animal    schedule 14.10.2012


Ответы (1)


Лучшее, что я могу собрать до сих пор, это:

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

Для варианта TLS II (i386 и т. д.) «регистр указателя потока» (который на самом деле может быть не регистром, а, возможно, каким-то механизмом, например %gs:0, или даже ловушкой в ​​пространстве ядра; для простоты давайте просто назовем его регистром) указывает сразу после конца сегмента TLS для основного исполняемого файла, где "сразу после конца" включает округление до следующего кратного выравнивания сегмента TLS.

Для варианта TLS I «регистр указателя потока» указывает на некоторое фиксированное смещение от начала сегмента TLS для основного исполняемого файла. Это смещение зависит от арки. (Это было выбрано на некоторых уродливых архитектурах RISC, чтобы максимизировать количество TLS, доступное через подписанные 16-битные смещения, что кажется мне крайне бесполезным, поскольку компилятор не может знать, уместится ли перемещенное смещение в 16 бит и, следовательно, должен всегда генерируйте более медленный код с большим 32-битным смещением, используя инструкции load-upper/add).

Насколько я могу судить, ничего о TCB, DTV и т. д. не является частью ABI, в том смысле, что приложениям не разрешен доступ к этим структурам, равно как и местоположение любого сегмента TLS, кроме части основного исполняемого файла АБИ. В обоих вариантах I и II имеет смысл хранить внутреннюю информацию реализации для потока с фиксированным смещением от «регистра указателя потока», в зависимости от того, каким образом безопасно избежать перекрытия сегмента TLS.

person R.. GitHub STOP HELPING ICE    schedule 15.10.2012