[llvm] [LLVM][rtsan] Add nosanitize_realtime instrumentation (PR #106125)
Chris Apple via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 29 11:33:24 PDT 2024
================
@@ -51,6 +53,7 @@ RealtimeSanitizerPass::RealtimeSanitizerPass(
PreservedAnalyses RealtimeSanitizerPass::run(Function &F,
AnalysisManager<Function> &AM) {
if (F.hasFnAttribute(Attribute::SanitizeRealtime)) {
+ assert(!F.hasFnAttribute(Attribute::NoSanitizeRealtime));
----------------
cjappl wrote:
Thanks for pointing that out, I wasn't aware it existed!
**Pros of ScopedDisabler:**
- Enables finer-grained disabling within a function.
- Avoids modifying LLVM attributes or Clang, simplifying the implementation.
- Precedent exists with lsan.
**Cons of ScopedDisabler:**
- Doesn't follow existing patterns for disabling interceptors, unlike asan and others.
- Users need to recreate build system infrastructure for conditional compilation with `-fsanitize=realtime`.
The biggest concern is that second "con" -- users would need to manually include out-of-project headers and manage build conditions, leading to some potential issues:
1. Duplication of effort across users.
2. Difficulty in locating the required header files. (and conditionally including them if the sanitizer is enabled, leading to more complex build systems)
3. Risk of users re-implementing ScopedDisabler in their codebases.
The `nosanitize` attribute is comparatively simpler, which "just works" without extra steps. I would prefer whatever solution we go forward with, it uses a construct that would be as non-invasive as the nosanitize approach to avoid burdening users with additional setup. Are there other solutions that provide this level of ease to the end user?
For finer-grained interception, we've advised extracting code into new functions and applying the nosanitize attribute. This approach is a little more invasive but clearly indicates that the code is treated differently.
https://github.com/llvm/llvm-project/pull/106125
More information about the llvm-commits
mailing list