================
@@ -248,12 +248,26 @@ compilers, so we suggest to use it together with
The same attribute used on a global variable prevents AddressSanitizer
from adding redzones around it and detecting out of bounds accesses.
-
AddressSanitizer also supports
``__attribute__((disable_sanitizer_instrumentation))``. This attribute
works similarly to ``__attribute__((no_sanitize("address")))``, but it also
prevents instrumentation performed by other sanitizers.
+Interaction of Inlining with Disabling Sanitizer Instrumentation
+-----------------------------------------------------------------
+
+* `no_sanitize` functions will not be inlined heuristically by the compiler.
+* Forcibly combining `no_sanitize` and ``__attribute__((always_inline))`` is
not supported, and will often lead to unexpected results. To avoid mixing these
attributes, use:
+
+.. code-block:: c
+
+ // Note, __has_feature test for sanitizers is deprecated, and Clang will
support __SANITIZE_<sanitizer>__ similar to GCC.
+ #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__) ||
... <other sanitizers>
----------------
melver wrote:
The old compilers that don't have __has_feature also have broken no_sanitize
AFAIK, so not sure if worth it.
__has_feature is pretty standard now, and in fact we're deprecating the
__has_feature(*sanitizer) checks (although the doc isn't updated for that yet).
https://github.com/llvm/llvm-project/pull/177672
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits