summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
diff options
context:
space:
mode:
authorKuba Brecka <kuba.brecka@gmail.com>2015-11-19 10:35:35 +0000
committerKuba Brecka <kuba.brecka@gmail.com>2015-11-19 10:35:35 +0000
commitefd92b3d16589f65bd762279697ab2add95ebd91 (patch)
tree356ae79f51e2b562abd2e8e2314c2c816a26943f /lldb/packages/Python/lldbsuite/test/lldbplatformutil.py
parentf278eb10b7dad7e081a29ff6d7f0f21fd3f37533 (diff)
downloadbcm5719-llvm-efd92b3d16589f65bd762279697ab2add95ebd91.tar.gz
bcm5719-llvm-efd92b3d16589f65bd762279697ab2add95ebd91.zip
[tsan] Handle dispatch_once on OS X
Reimplement dispatch_once in an interceptor to solve these issues that may produce false positives with TSan on OS X: 1) there is a racy load inside an inlined part of dispatch_once, 2) the fast path in dispatch_once doesn't perform an acquire load, so we don't properly synchronize the initialization and subsequent uses of whatever is initialized, 3) dispatch_once is already used in a lot of already-compiled code, so TSan doesn't see the inlined fast-path. This patch uses a trick to avoid ever taking the fast path (by never storing ~0 into the predicate), which means the interceptor will always be called even from already-compiled code. Within the interceptor, our own atomic reads and writes are not written into shadow cells, so the race in the inlined part is not reported (because the accesses are only loads). Differential Revision: http://reviews.llvm.org/D14811 llvm-svn: 253552
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/lldbplatformutil.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud