aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorShoaib Meenai <smeenai@fb.com>2021-07-29 18:39:04 -0700
committerShoaib Meenai <smeenai@fb.com>2021-07-30 14:52:38 -0700
commitb8f04a670f27a84412099dd025fa762ee58f4c1a (patch)
treee48d527e60f90797cc7c0638bd164af91134d826 /flang/lib/Frontend/CompilerInvocation.cpp
parent6ea2f31f3d7024c22c619956b13bafe945d11ca1 (diff)
downloadllvm-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