Почему LTO вводит новые флаги DT TLSDESC_PLT и TLSDESC_GOT в сборке armv8a NDK - PullRequest
Новая
       50

Почему LTO вводит новые флаги DT TLSDESC_PLT и TLSDESC_GOT в сборке armv8a NDK

0 голосов
/ 23 мая 2018

Я создаю armv8a SDK для Android, используя NDK, и я хотел собрать с включенным LTO.Я добавил -flto к флагам компиляции и ссылки для цепочки инструментов C ++, и все шло хорошо, пока я не попытался запустить в эмуляторе, после чего возникла ошибка, подобная следующей:

WARNING: linker: /data/lib/libservice.so: unused DT entry: type 0x6ffffef6 arg 0x8e30

и

WARNING: linker: /data/lib/libservice.so: unused DT entry: type 0x6ffffef7 arg 0x2fb50

Некоторые исследования привели меня к этому ответу , который позволил мне выкопать имена символов для 0x6ffffef6 и 0x6ffffef6, они оказываются TLSDESC_PLT и TLSDESC_GOT соответственно, так что явно что-то связано с динамическим компоновщиком и PLT / GOT, а также с TLS.Отлично.

Сравнивая сборку без LTO со сборкой LTO, эти флаги определенно подходят только для сборки LTO:

$ readelf -a /lto/lib/libservice.so | grep TLS L (link order), O (extra OS processing required), G (group), T (TLS), TLS 0x000000000001ed70 0x000000000002ed70 0x000000000002ed70 0x000000006ffffef6 (TLSDESC_PLT) 0x8e30 0x000000006ffffef7 (TLSDESC_GOT) 0x2fb50 00000002ffd8 000000000407 R_AARCH64_TLSDESC 0 00000002ffe8 000000000407 R_AARCH64_TLSDESC 8 579: 0000000000000008 8 TLS LOCAL DEFAULT 17 _ZN5xxxxx12_GLOBAL__N_113 788: 0000000000000000 1 TLS LOCAL DEFAULT 17 __tls_guard $

$ readelf -a /nolto/lib/libservice.so | grep TLS L (link order), O (extra OS processing required), G (group), T (TLS), $

Итак, некоторые вопросы:

  • Почему среда выполнения android armv8a отклоняет эти флаги DT?
  • Почему включение LTO, похоже, меняет реализацию TLS или потребности?Почему эти теги испускаются (вместе с другими символами)?
  • Как я могу предотвратить это или иным образом избежать этой проблемы?Могу ли я запросить какую-либо другую модель TLS?
  • Я обнаружил, по крайней мере, еще одну проблему, подобную этой, когда среда Android отклоняет флаг DT_ORIGIN, который обычно требуется для обработки $ORIGIN, но все же учитывается $ORIGIN даже без DT_ORIGIN набора.Является ли отклонение флагов TLDESC_ потенциально слишком переусердствующей проверкой, и код на самом деле в порядке, что указывает на ошибку NDK?

Любые идеи приветствуются.Обратите внимание, что это, похоже, работает для других целей Android, в частности сборка Android x86_64 работала просто отлично с -flto, и в полученных двоичных файлах TLSDESC ничего не было в выводе readelf -a.

1 Ответ

0 голосов
/ 24 августа 2018

Я обновился до NDK r18 beta2, и у меня больше нет этой проблемы.Похоже, что основная ошибка была связана с не распространением использования эмулируемого TLS через плагин gold linker (см. https://github.com/android-ndk/ndk/issues/498),, который был исправлен в r18.

...