[clang] [rtsan][NFC] Documentation of suppression flag (PR #112727)
via cfe-commits
cfe-commits at lists.llvm.org
Thu Oct 17 09:44:27 PDT 2024
================
@@ -194,12 +198,43 @@ Some issues with flags can be debugged using the ``verbosity=$NUM`` flag:
misspelled_flag
...
-Disabling
----------
+Disabling and suppressing
+-------------------------
-In some circumstances, you may want to suppress error reporting in a specific scope.
+There are multiple ways to suppress error reporting when using RealtimeSanitizer.
-In C++, this is achieved via ``__rtsan::ScopedDisabler``. Within the scope where the ``ScopedDisabler`` object is instantiated, all sanitizer error reports are suppressed. This suppression applies to the current scope as well as all invoked functions, including any functions called transitively.
+In general, ``ScopedDisabler`` should be preferred, as it is the most performant.
+
+.. list-table:: Suppression methods
+ :widths: 30 15 15 10 70
+ :header-rows: 1
+
+ * - Suppression method
+ - Specified at?
+ - Scope
+ - Run-time cost
+ - Description
+ * - ``ScopedDisabler``
+ - Compile-time
+ - Stack
+ - Very low
----------------
davidtrevelyan wrote:
Totally understood, and well phrased question - is what is happening under the hood helpful? In general it depends on the context, of course. For something like choosing between `std::map` vs `std::unordered_map` for performance reasons, it's critical to know what's happening under the hood. For choosing what json library to use in an application that isn't performance sensitive, it doesn't matter - I just care about the API being easy to use. So where does rtsan fall on that spectrum? I think probably somewhere in the middle, but I suspect leaning more towards the "I don't care" side. So maybe we just leave this as it is, and add more detail if people request it? I don't feel strongly either way on this one, just wanted to raise the question in case it rung some alarm bells.
https://github.com/llvm/llvm-project/pull/112727
More information about the cfe-commits
mailing list