diff options
author | Shoaib Meenai <smeenai@fb.com> | 2021-07-29 18:39:04 -0700 |
---|---|---|
committer | Shoaib Meenai <smeenai@fb.com> | 2021-07-30 14:52:38 -0700 |
commit | b8f04a670f27a84412099dd025fa762ee58f4c1a (patch) | |
tree | e48d527e60f90797cc7c0638bd164af91134d826 /flang/lib/Frontend/CompilerInvocation.cpp | |
parent | 6ea2f31f3d7024c22c619956b13bafe945d11ca1 (diff) | |
download | llvm-b8f04a670f27a84412099dd025fa762ee58f4c1a.zip llvm-b8f04a670f27a84412099dd025fa762ee58f4c1a.tar.gz llvm-b8f04a670f27a84412099dd025fa762ee58f4c1a.tar.bz2 |
[builtins] Try to ensure single copy of emulated TLS state
Multiple copies of emulated TLS state means inconsistent results when
accessing the same thread-local variable from different shared objects
(https://github.com/android/ndk/issues/1551). Making `__emutls_get_address`
be a weak default visibility symbol should make the dynamic linker
ensure only a single copy gets used at runtime. This is best-effort, but
the more robust approach of putting emulated TLS into its own shared
object would (a) be a much bigger change, and (b) shared objects are
pretty heavyweight, and adding a new one to a space-constrained
environment isn't an easy sell. Given the expected rarity of direct
accesses to emulated TLS variables across different shared objects, the
best-effort approach should suffice.
Reviewed By: danalbert, rprichard
Differential Revision: https://reviews.llvm.org/D107127
Diffstat (limited to 'flang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions