summaryrefslogtreecommitdiffstats
path: root/compiler-rt/include/sanitizer/tsan_interface.h
Commit message (Collapse)AuthorAgeFilesLines
* Dmitry Vyukov2019-02-131-0/+18
| | | | | | | | | | | | | | | | | | | | | | | tsan: add fiber support This patch adds functions for managing fibers: __tsan_get_current_fiber() __tsan_create_fiber() __tsan_destroy_fiber() __tsan_switch_to_fiber() __tsan_set_fiber_name() See the added tests for use examples. Author: yuri (Yuri Per) Reviewed in: https://reviews.llvm.org/D54889 [The previous commit of this change was reverted, this is a resubmit with a squashed fix for check_analyze.sh and COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED] llvm-svn: 353947
* Revert "tsan: add fiber support"Diana Picus2019-02-131-18/+0
| | | | | | | This reverts commit r353817 because we think it broke AARch64 and PowerPC buildbots. llvm-svn: 353939
* tsan: add fiber supportDmitry Vyukov2019-02-121-0/+18
| | | | | | | | | | | | | | | | | This patch adds functions for managing fibers: __tsan_get_current_fiber() __tsan_create_fiber() __tsan_destroy_fiber() __tsan_switch_to_fiber() __tsan_set_fiber_name() See the added tests for use examples. Author: yuri (Yuri Per) Reviewed in: https://reviews.llvm.org/D54889 llvm-svn: 353817
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [tsan] Add Mutex annotation flag for constant-initialized ↵Dmitry Vyukov2017-10-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | __tsan_mutex_linker_init behavior Add a new flag, _⁠_tsan_mutex_not_static, which has the opposite sense of _⁠_tsan_mutex_linker_init. When the new _⁠_tsan_mutex_not_static flag is passed to _⁠_tsan_mutex_destroy, tsan ignores the destruction unless the mutex was also created with the _⁠_tsan_mutex_not_static flag. This is useful for constructors that otherwise woud set _⁠_tsan_mutex_linker_init but cannot, because they are declared constexpr. Google has a custom mutex with two constructors, a "linker initialized" constructor that relies on zero-initialization and sets ⁠_⁠_tsan_mutex_linker_init, and a normal one which sets no tsan flags. The "linker initialized" constructor is morally constexpr, but we can't declare it constexpr because of the need to call into tsan as a side effect. With this new flag, the normal c'tor can set _⁠_tsan_mutex_not_static, the "linker initialized" constructor can rely on tsan's lazy initialization, and _⁠_tsan_mutex_destroy can still handle both cases correctly. Author: Greg Falcon (gfalcon) Reviewed in: https://reviews.llvm.org/D39095 llvm-svn: 316209
* [tsan] Detect races on modifying accesses in Swift codeKuba Mracek2017-05-031-0/+1
| | | | | | | | This patch allows the Swift compiler to emit calls to `__tsan_external_write` before starting any modifying access, which will cause TSan to detect races on arrays, dictionaries and other classes defined in non-instrumented modules. Races on collections from the Swift standard library and user-defined structs and a frequent cause of subtle bugs and it's important that TSan detects those on top of existing LLVM IR instrumentation, which already detects races in direct memory accesses. Differential Revision: https://reviews.llvm.org/D31630 llvm-svn: 302050
* tsan: support linker init flag in __tsan_mutex_destroyDmitry Vyukov2017-05-011-1/+2
| | | | | | | | | | | | | | For a linker init mutex with lazy flag setup (no __tsan_mutex_create call), it is possible that no lock/unlock happened before the destroy call. Then when destroy runs we still don't know that it is a linker init mutex and will emulate a memory write. This in turn can lead to false positives as the mutex is in fact linker initialized. Support linker init flag in destroy annotation to resolve this. llvm-svn: 301795
* [tsan] Publish the TSan external API in tsan_interface.hKuba Mracek2017-04-211-0/+15
| | | | | | | | | | | | | Let's make the TSan external API available and commented in the public header: void *__tsan_external_register_tag(const char *object_type); void __tsan_external_assign_tag(void *addr, void *tag); void __tsan_external_read(void *addr, void *caller_pc, void *tag); void __tsan_external_write(void *addr, void *caller_pc, void *tag); Differential Revision: https://reviews.llvm.org/D32358 llvm-svn: 301003
* tsan: add new mutex annotationsDmitry Vyukov2017-03-261-0/+121
There are several problems with the current annotations (AnnotateRWLockCreate and friends): - they don't fully support deadlock detection (we need a hook _before_ mutex lock) - they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock) - they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on) - they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes) - they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments. Reviewed in https://reviews.llvm.org/D31093 llvm-svn: 298809
OpenPOWER on IntegriCloud