Why does LTO introduce new DT flags TLSDESC_PLT and TLSDESC_GOT in armv8a NDK build

I'm building an armv8a SDK for Android using the NDK and I wanted to build with LTO enabled. I added -flto to the compile and link flags for the C++ toolchain, and all went well, until I tried to run in the emulator, at which point an error like the following was emitted:

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

and

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

Some research led me to this answer which allowed me to dig out the symbol names for 0x6ffffef6 and 0x6ffffef6, they happen to be TLSDESC_PLT and TLSDESC_GOT respectively, so clearly something to do with dynamic linker and the PLT/GOT, and also with TLS. Fine.

Comparing the non LTO build with the LTO build, these flags definitely only come in for the LTO build:

$ 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), $

So, some questions:

• Why does the android armv8a runtime reject these DT flags?
• Why does enabling LTO seem to change the TLS implementation or needs? Why do these tags get emitted (along with the other symbols)?
• How can I prevent that, or otherwise avoid this issue? Can I request some other TLS model?
• I've found at least one other issue like this, where the Android environment rejects the flag DT_ORIGIN which is usually required for $ORIGIN processing, but still honors $ORIGIN even without DT_ORIGIN set. Is the rejection of the TLDESC_ flags potentially a similarly overzealous check, and the code is in fact fine, which would indicate an NDK bug?

Any insights appreciated. Note that this seems to work for other Android targets, specifically the Android x86_64 build worked just fine with -flto, and the resulting binaries do not have any TLSDESC anything in the readelf -a output.

from Why does LTO introduce new DT flags TLSDESC_PLT and TLSDESC_GOT in armv8a NDK build