summaryrefslogtreecommitdiffstats
path: root/clang/docs/UndefinedBehaviorSanitizer.rst
Commit message (Collapse)AuthorAgeFilesLines
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* [docs] Add a note about where UBSan emits logsVedant Kumar2019-07-291-0/+6
| | | | llvm-svn: 367270
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* [Docs] Modernize references to macOSJ. Ryan Stinnett2019-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This updates all places in documentation that refer to "Mac OS X", "OS X", etc. to instead use the modern name "macOS" when no specific version number is mentioned. If a specific version is mentioned, this attempts to use the OS name at the time of that version: * Mac OS X for 10.0 - 10.7 * OS X for 10.8 - 10.11 * macOS for 10.12 - present Reviewers: JDevlieghere Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits Tags: #clang, #lldb, #libc, #llvm Differential Revision: https://reviews.llvm.org/D62654 llvm-svn: 362113
* [Documentation] Use HTTPS whenever possibleEugene Zelenko2019-01-231-1/+1
| | | | | | Differential revision: https://reviews.llvm.org/D56946 llvm-svn: 351976
* [clang][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: UB isn't nice. It's cool and powerful, but not nice. Having a way to detect it is nice though. [[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says: ``` We propose to add this functionality via a library function instead of a core language attribute. ... If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour. ``` This differential teaches clang to sanitize all the various variants of this assume-aligned attribute. Requires D54588 for LLVM IRBuilder changes. The compiler-rt part is D54590. This is a second commit, the original one was r351105, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall Reviewed By: rjmccall Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54589 llvm-svn: 351177
* Revert alignment assumptions changesVlad Tsyrklevich2019-01-151-1/+1
| | | | | | | Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These changes fail on the sanitizer bots. llvm-svn: 351159
* [clang][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: UB isn't nice. It's cool and powerful, but not nice. Having a way to detect it is nice though. [[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says: ``` We propose to add this functionality via a library function instead of a core language attribute. ... If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour. ``` This differential teaches clang to sanitize all the various variants of this assume-aligned attribute. Requires D54588 for LLVM IRBuilder changes. The compiler-rt part is D54590. Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall Reviewed By: rjmccall Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54589 llvm-svn: 351105
* [docs] UBSan and ASan are supported on WindowsReid Kleckner2018-11-271-1/+7
| | | | | | | | Also fix a bullet list. Fixes PR39775 llvm-svn: 347633
* Update our URLs in clang doc to use httpsSylvestre Ledru2018-11-041-1/+1
| | | | llvm-svn: 346101
* [clang][ubsan] Implicit Conversion Sanitizer - integer sign change - clang partRoman Lebedev2018-10-301-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second half of Implicit Integer Conversion Sanitizer. It completes the first half, and finally makes the sanitizer fully functional! Only the bitfield handling is missing. Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` void consume(unsigned int val); void test(int val) { consume(val); // The 'val' is `signed int`, but `consume()` takes `unsigned int`. // If val is negative, then consume() will be operating on a large // unsigned value, and you may or may not have a bug. // But yes, sometimes this is intentional. // Making the conversion explicit silences the sanitizer. consume((unsigned int)val); } ``` Yes, there is a `-Wsign-conversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, likely there are cases where it does **not** warn. The actual detection is pretty easy. We just need to check each of the values whether it is negative, and equality-compare the results of those comparisons. The unsigned value is obviously non-negative. Zero is non-negative too. https://godbolt.org/g/w93oj2 We do not have to emit the check *always*, there are obvious situations where we can avoid emitting it, since it would **always** get optimized-out. But i do think the tautological IR (`icmp ult %x, 0`, which is always false) should be emitted, and the middle-end should cleanup it. This sanitizer is in the `-fsanitize=implicit-conversion` group, and is a logical continuation of D48958 `-fsanitize=implicit-integer-truncation`. As for the ordering, i'we opted to emit the check **after** `-fsanitize=implicit-integer-truncation`. At least on these simple 16 test cases, this results in 1 of the 12 emitted checks being optimized away, as compared to 0 checks being optimized away if the order is reversed. This is a clang part. The compiler-rt part is D50251. Finishes fixing [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Finishes partially fixing [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Finishes fixing https://github.com/google/sanitizers/issues/940. Only the bitfield handling is missing. Reviewers: vsk, rsmith, rjmccall, #sanitizers, erichkeane Reviewed By: rsmith Subscribers: chandlerc, filcab, cfe-commits, regehr Tags: #sanitizers, #clang Differential Revision: https://reviews.llvm.org/D50250 llvm-svn: 345660
* [clang][ubsan] Split Implicit Integer Truncation Sanitizer into unsigned and ↵Roman Lebedev2018-10-111-2/+11
| | | | | | | | | | | | | | | | | | | | signed checks Summary: As per IRC disscussion, it seems we really want to have more fine-grained `-fsanitize=implicit-integer-truncation`: * A check when both of the types are unsigned. * Another check for the other cases (either one of the types is signed, or both of the types is signed). This is clang part. Compiler-rt part is D50902. Reviewers: rsmith, vsk, Sanitizers Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D50901 llvm-svn: 344230
* [docs] UndefinedBehaviorSanitizer.rst: {,un}signed-integer-overflow: tune docsRoman Lebedev2018-07-301-2/+2
| | | | | | | | | | | | | Yes, i erroneously assumed that the "after" was meant, but i was wrong: > I really meant "performed before", for cases like 4u / -2, > where -2 is implicitly converted to UINT_MAX - 2 before > the computation. Conversions that are performed after > a computation aren't part of the computation at all, > so I think it's much clearer that they're not in scope > for this sanitizer. llvm-svn: 338306
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-301-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
* [Docs] Update supported oses for safestack, ubsan, asan, tsan and msanDavid Carlier2018-07-251-8/+2
| | | | | | Adding oses others than Linux. llvm-svn: 337926
* [UBSan] Add silence_unsigned_overflow flag.Matt Morehouse2018-06-271-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO reports. This feature, combined with -fsanitize-recover=unsigned-integer-overflow, is useful for providing fuzzing signal without the excessive log output. Helps with https://github.com/google/oss-fuzz/issues/910. Reviewers: kcc, vsk Reviewed By: vsk Subscribers: vsk, kubamracek, Dor1s, llvm-commits Differential Revision: https://reviews.llvm.org/D48660 llvm-svn: 335762
* [ubsan] Diagnose noreturn functions which returnVedant Kumar2017-12-211-2/+2
| | | | | | | | | | | | | | | | | | Diagnose 'unreachable' UB when a noreturn function returns. 1. Insert a check at the end of functions marked noreturn. 2. A decl may be marked noreturn in the caller TU, but not marked in the TU where it's defined. To diagnose this scenario, strip away the noreturn attribute on the callee and insert check after calls to it. Testing: check-clang, check-ubsan, check-ubsan-minimal, D40700 rdar://33660464 Differential Revision: https://reviews.llvm.org/D40698 llvm-svn: 321231
* [ubsan] Enable -fsanitize=function on DarwinVedant Kumar2017-09-131-1/+2
| | | | | | https://reviews.llvm.org/D37598 llvm-svn: 313099
* [ubsan-minimal] Document the new runtimeVedant Kumar2017-09-111-0/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D37647 llvm-svn: 312957
* [docs] Remove accidental unindent to appease the sphinx botVedant Kumar2017-08-021-4/+4
| | | | | | | Bot failure: http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/12043/steps/docs-clang-html/logs/stdio llvm-svn: 309852
* [ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't ↵Vedant Kumar2017-08-021-4/+4
| | | | | | | | | | | | | | | | | | available In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible. In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null. Differential Revision: https://reviews.llvm.org/D36112 llvm-svn: 309846
* [ubsan] Diagnose invalid uses of builtins (clang)Vedant Kumar2017-07-291-0/+1
| | | | | | | | | | | | | | | On some targets, passing zero to the clz() or ctz() builtins has undefined behavior. I ran into this issue while debugging UB in __hash_table from libcxx: the bug I was seeing manifested itself differently under -O0 vs -Os, due to a UB call to clz() (see: libcxx/r304617). This patch introduces a check which can detect UB calls to builtins. llvm.org/PR26979 Differential Revision: https://reviews.llvm.org/D34590 llvm-svn: 309459
* [ubsan] Null-check pointers in -fsanitize=vptr (PR33881)Vedant Kumar2017-07-251-5/+5
| | | | | | | | | | | | | | | | | | | The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
* [ubsan] docs: Add a note about pointers to volatileVedant Kumar2017-06-161-0/+6
| | | | llvm-svn: 305568
* [ubsan] Add a check for pointer overflow UBVedant Kumar2017-06-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check pointer arithmetic for overflow. For some more background on this check, see: https://wdtz.org/catching-pointer-overflow-bugs.html https://reviews.llvm.org/D20322 Patch by Will Dietz and John Regehr! This version of the patch is different from the original in a few ways: - It introduces the EmitCheckedInBoundsGEP utility which inserts checks when the pointer overflow check is enabled. - It does some constant-folding to reduce instrumentation overhead. - It does not check some GEPs in CGExprCXX. I'm not sure that inserting checks here, or in CGClass, would catch many bugs. Possible future directions for this check: - Introduce CGF.EmitCheckedStructGEP, to detect overflows when accessing structures. Testing: Apart from the added lit test, I ran check-llvm and check-clang with a stage2, ubsan-instrumented clang. Will and John have also done extensive testing on numerous open source projects. Differential Revision: https://reviews.llvm.org/D33305 llvm-svn: 304459
* Revert "[docs] UBSan: Mention that print_stacktrace=1 is unsupported on Darwin"Vedant Kumar2017-05-021-2/+0
| | | | | | | | | This reverts commit r300295. It's no longer true, print_stacktrace=1 is supported on Darwin/Windows as of r301839. llvm-svn: 301960
* [docs] UBSan: Mention that print_stacktrace=1 is unsupported on DarwinVedant Kumar2017-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Printing out stack traces along with UBSan diagnostics is unsupported on Darwin. That's because it isn't possible to use the fast unwinder or the slow unwinder. Apparently, it's inappropriate to use the fast unwinder for UBSan issues. I'm not exactly sure why (see the comment in ubsan_diag.cc). Forcing use of the fast unwinder produces decent results, AFAICT. Darwin also does not appear to have a slow unwinder suitable for use with the sanitizers. Apparently that's because of PR20800 [1][2]. But that bug has been fixed. I'm not sure if there is anything preventing use of the slow unwinder now. Currently, passing UBSAN_OPTIONS=print_stacktrace=1 does nothing on Darwin. This isn't good, but it might be a while before we can fix the situation, so we should at least document it. [1] https://github.com/google/sanitizers/issues/137 "We can't use the slow unwinder on OSX now, because Clang produces incorrect unwind info for the ASan runtime functions on OSX (http://llvm.org/PR20800)." [2] https://bugs.llvm.org/show_bug.cgi?id=20800 Bug 20800 - Invalid compact unwind info generated for a function without frame pointers on OSX llvm-svn: 300295
* [docs] Clarify sanitizer flag behaviorVedant Kumar2017-03-201-3/+3
| | | | | | | | 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. llvm-svn: 298310
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* UBSan docs: Explicitly mention that `-fsanitize=unsigned-integer-overflow` ↵Nico Weber2017-02-271-1/+3
| | | | | | | | does not catch UB. https://reviews.llvm.org/D27455 llvm-svn: 296387
* Fix typo in documentation.Nick Lewycky2016-09-201-2/+2
| | | | | | Since this is a header it will break links to this section. llvm-svn: 281996
* [ubsan] Add -fsanitize-undefined-strip-path-components=NFilipe Cabecinhas2016-05-121-0/+20
| | | | | | | | | | | | | | | | | | | 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 llvm-svn: 269309
* [Docs] Fix indentation error introduced by r267447.George Burgess IV2016-04-261-7/+7
| | | | llvm-svn: 267501
* [Docs] Clarify what the object-size sanitizer does.George Burgess IV2016-04-251-5/+8
| | | | | | | | | | 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. llvm-svn: 267447
* [UBSan] Add documentation for runtime issue suppression.Alexey Samsonov2016-01-291-0/+32
| | | | llvm-svn: 259260
* [Docs] One more cleanup of -fsanitize= section.Alexey Samsonov2015-12-041-1/+3
| | | | | | | Describe -fsanitize-blacklist flags in separate paragraphs, move notes about importance of clang++ for vptr down to UBSan docs. llvm-svn: 254798
* Clang documentation for UBSan.Alexey Samsonov2015-12-041-0/+202
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 llvm-svn: 254733
OpenPOWER on IntegriCloud