aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/StringRef.cpp
diff options
context:
space:
mode:
authorDmitry Vyukov <dvyukov@google.com>2021-12-02 15:15:14 +0100
committerDmitry Vyukov <dvyukov@google.com>2021-12-02 17:47:05 +0100
commit97b4e631173a5f2f1f79361f9fc56c8f85681f73 (patch)
treed84c952e0bd795da5e124af8b0e909e65e98ceef /llvm/lib/Support/StringRef.cpp
parent6f5c5cbe5f8209de3f4d91de75d7f3a716e9f131 (diff)
downloadllvm-97b4e631173a5f2f1f79361f9fc56c8f85681f73.zip
llvm-97b4e631173a5f2f1f79361f9fc56c8f85681f73.tar.gz
llvm-97b4e631173a5f2f1f79361f9fc56c8f85681f73.tar.bz2
tsan: fix false positives in dynamic libs with static tls
The added test demonstrates loading a dynamic library with static TLS. Such static TLS is a hack that allows a dynamic library to have faster TLS, but it can be loaded only iff all threads happened to allocate some excess of static TLS space for whatever reason. If it's not the case loading fails with: dlopen: cannot load any more object with static TLS We used to produce a false positive because dlopen will write into TLS of all existing threads to initialize/zero TLS region for the loaded library. And this appears to be racing with initialization of TLS in the thread since we model a write into the whole static TLS region (we don't what part of it is currently unused): WARNING: ThreadSanitizer: data race (pid=2317365) Write of size 1 at 0x7f1fa9bfcdd7 by main thread: 0 memset 1 init_one_static_tls 2 __pthread_init_static_tls [[ this is where main calls dlopen ]] 3 main Previous write of size 8 at 0x7f1fa9bfcdd0 by thread T1: 0 __tsan_tls_initialization Fix this by ignoring accesses during dlopen. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D114953
Diffstat (limited to 'llvm/lib/Support/StringRef.cpp')
0 files changed, 0 insertions, 0 deletions