diff options
author | Vedant Kumar <vsk@apple.com> | 2017-03-14 01:56:34 +0000 |
---|---|---|
committer | Vedant Kumar <vsk@apple.com> | 2017-03-14 01:56:34 +0000 |
commit | 42c17ec5ac8cadf351ec63234124ab40d59feaab (patch) | |
tree | f6a0e73e9255b7eb697c4626139394c59b9d2feb /clang/docs | |
parent | 620f86ff2bbe6107ca7d0b95c93c7201cd3edcb5 (diff) | |
download | bcm5719-llvm-42c17ec5ac8cadf351ec63234124ab40d59feaab.tar.gz bcm5719-llvm-42c17ec5ac8cadf351ec63234124ab40d59feaab.zip |
[ubsan] Add a nullability sanitizer
Teach UBSan to detect when a value with the _Nonnull type annotation
assumes a null value. Call expressions, initializers, assignments, and
return statements are all checked.
Because _Nonnull does not affect IRGen, the new checks are disabled by
default. The new driver flags are:
-fsanitize=nullability-arg (_Nonnull violation in call)
-fsanitize=nullability-assign (_Nonnull violation in assignment)
-fsanitize=nullability-return (_Nonnull violation in return stmt)
-fsanitize=nullability (all of the above)
This patch builds on top of UBSan's existing support for detecting
violations of the nonnull attributes ('nonnull' and 'returns_nonnull'),
and relies on the compiler-rt support for those checks. Eventually we
will need to update the diagnostic messages in compiler-rt (there are
FIXME's for this, which will be addressed in a follow-up).
One point of note is that the nullability-return check is only allowed
to kick in if all arguments to the function satisfy their nullability
preconditions. This makes it necessary to emit some null checks in the
function body itself.
Testing: check-clang and check-ubsan. I also built some Apple ObjC
frameworks with an asserts-enabled compiler, and verified that we get
valid reports.
Differential Revision: https://reviews.llvm.org/D30762
llvm-svn: 297700
Diffstat (limited to 'clang/docs')
-rw-r--r-- | clang/docs/UndefinedBehaviorSanitizer.rst | 12 |
1 files changed, 11 insertions, 1 deletions
diff --git a/clang/docs/UndefinedBehaviorSanitizer.rst b/clang/docs/UndefinedBehaviorSanitizer.rst index 7ff7be93184..f9111ee846d 100644 --- a/clang/docs/UndefinedBehaviorSanitizer.rst +++ b/clang/docs/UndefinedBehaviorSanitizer.rst @@ -92,6 +92,12 @@ Available checks are: parameter which is declared to never be null. - ``-fsanitize=null``: Use of a null pointer or creation of a null reference. + - ``-fsanitize=nullability-arg``: Passing null as a function parameter + which is annotated with ``_Nonnull``. + - ``-fsanitize=nullability-assign``: Assigning null to an lvalue which + is annotated with ``_Nonnull``. + - ``-fsanitize=nullability-return``: Returning null from a function with + a return type annotated with ``_Nonnull``. - ``-fsanitize=object-size``: An attempt to potentially use bytes which the optimizer can determine are not part of the object being accessed. This will also detect some types of undefined behavior that may not @@ -130,11 +136,15 @@ Available checks are: You can also use the following check groups: - ``-fsanitize=undefined``: All of the checks listed above other than - ``unsigned-integer-overflow``. + ``unsigned-integer-overflow`` and the ``nullability-*`` checks. - ``-fsanitize=undefined-trap``: Deprecated alias of ``-fsanitize=undefined``. - ``-fsanitize=integer``: Checks for undefined or suspicious integer behavior (e.g. unsigned integer overflow). + - ``-fsanitize=nullability``: Enables ``nullability-arg``, + ``nullability-assign``, and ``nullability-return``. While violating + nullability does not have undefined behavior, it is often unintentional, + so UBSan offers to catch it. Stack traces and report symbolization ===================================== |