PR32346 suggests that UBSan's docs about the -fsanitize,
-fno-sanitize-recover, and -fsanitize-trap options are not explicit
enough. Try to improve the wording.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298310 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@297700 91177308-0d34-0410-b5e6-96231b3b80d8

https://reviews.llvm.org/D27455


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296387 91177308-0d34-0410-b5e6-96231b3b80d8

Since this is a header it will break links to this section.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281996 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This option allows the user to control how much of the file name is
emitted by UBSan. Tuning this option allows one to save space in the
resulting binary, which is helpful for restricted execution
environments.

With a positive N, UBSan skips the first N path components.
With a negative N, UBSan only keeps the last N path components.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D19666

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269309 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267501 91177308-0d34-0410-b5e6-96231b3b80d8

Currently, the UBSan docs make it sound like the object-size sanitizer
will only detect out-of-bounds reads/writes. It also catches some
operations that don't necessarily access memory (invalid downcasts,
calls of methods on invalid pointers, ...). This patch adds a note
about this behavior in the docs.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267447 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259260 91177308-0d34-0410-b5e6-96231b3b80d8

Describe -fsanitize-blacklist flags in separate paragraphs, move
notes about importance of clang++ for vptr down to UBSan docs.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254798 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Create a separate page describing UBSan tool, move the description of
fine-grained checks there, provide extra information about supported
platforms, symbolization etc. This text is compiled from four parts:

* Existing documentation copied from User's Manual
* Layout used in documentation for another sanitizers (ASan, MSan etc.)
* Text written from scratch
* Small parts taken from Michael Morrison's attempt at creating UBSan
  page:
  http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20141215/249503.html

Reviewers: kcc, rsmith, silvas

Subscribers: tberghammer, danalbert, srhines, kcc

Differential Revision: http://reviews.llvm.org/D15217

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254733 91177308-0d34-0410-b5e6-96231b3b80d8