forked from OSchip/llvm-project
5a2c31116f
Add support to optionally emit different instrumentation for accesses to volatile variables. While the default TSAN runtime likely will never require this feature, other runtimes for different environments that have subtly different memory models or assumptions may require distinguishing volatiles. One such environment are OS kernels, where volatile is still used in various places for various reasons, and often declare volatile to be "safe enough" even in multi-threaded contexts. One such example is the Linux kernel, which implements various synchronization primitives using volatile (READ_ONCE(), WRITE_ONCE()). Here the Kernel Concurrency Sanitizer (KCSAN) [1], is a runtime that uses TSAN instrumentation but otherwise implements a very different approach to race detection from TSAN. While in the Linux kernel it is generally discouraged to use volatiles explicitly, the topic will likely come up again, and we will eventually need to distinguish volatile accesses [2]. The other use-case is ignoring data races on specially marked variables in the kernel, for example bit-flags (here we may hide 'volatile' behind a different name such as 'no_data_race'). [1] https://github.com/google/ktsan/wiki/KCSAN [2] https://lkml.kernel.org/r/CANpmjNOfXNE-Zh3MNP=-gmnhvKbsfUfTtWkyg_=VqTxS4nnptQ@mail.gmail.com Author: melver (Marco Elver) Reviewed-in: https://reviews.llvm.org/D78554 |
||
|---|---|---|
| .. | ||
| AddressSanitizer | ||
| BoundsChecking | ||
| DataFlowSanitizer | ||
| HWAddressSanitizer | ||
| InstrOrderFile | ||
| InstrProfiling | ||
| MemorySanitizer | ||
| PoisonChecking | ||
| SanitizerCoverage | ||
| ThreadSanitizer | ||
| cgprofile.ll | ||