summaryrefslogtreecommitdiffstats
path: root/clang/test/Driver/fsanitize.c
Commit message (Collapse)AuthorAgeFilesLines
* [Driver] Support -fsanitize=shadow-call-stack and cfi-icall on aarch64_beFangrui Song2020-06-241-2/+3
| | | | | | | D80647 did not fix https://bugs.llvm.org/show_bug.cgi?id=46076 This is the fix. (cherry picked from commit b9c6871a9570975827dc0bbeb39131c99c8daf8e)
* [Driver] Support -fsanitize=shadow-call-stack on aarch64_beFangrui Song2020-06-241-0/+4
| | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=46076 Reviewed By: nickdesaulniers, pcc Differential Revision: https://reviews.llvm.org/D80647 (cherry picked from commit a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69)
* [AArch64] Make the memtag sanitizer require the memtag extensionMomchil Velikov2019-08-131-0/+10
| | | | | | | | ... or otherwise we get an ICE. Differential Revision: https://reviews.llvm.org/D65508 llvm-svn: 368696
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
* hwasan: Instrument globals.Peter Collingbourne2019-08-061-0/+2
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [Driver] Support -fsanitize=function on Solaris/x86Rainer Orth2019-07-301-0/+3
| | | | | | | | | | | | | | | | UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently FAILs on Solaris/x86_64: clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11' AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only), which is what this patch does, together with updating another testcase. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64488 llvm-svn: 367351
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-1/+4
| | | | | | | | | | | | | | | | | | | | | 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
* ARM MTE stack sanitizer.Evgeniy Stepanov2019-07-151-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
* clang/test/Driver/fsanitize.c: Fix -fsanitize=vptr using default targetFangrui Song2019-07-131-1/+1
| | | | | | | | | | | | The default implementation of getSupportedSanitizers isn't able to turn on the vptr sanitizer, and thus, any platform that runs this test will fail with the error: clang: error: unsupported option '-fsanitize=vptr' for target '<target>' Patch by James Nagurne! llvm-svn: 365981
* test/Driver/fsanitize.c: delete -target x86_64-linux-gnu from tests that ↵Fangrui Song2019-07-121-21/+21
| | | | | | | | should always be available Follow-up of D64317/r365587. llvm-svn: 365872
* [Driver] Add float-divide-by-zero back to supported sanitizers after ↵Fangrui Song2019-07-101-0/+14
| | | | | | | | | | | | | | | | | | D63793/rC365272 D63793 removed float-divide-by-zero from the "undefined" set but it failed to add it to getSupportedSanitizers(), thus the sanitizer is rejected by the driver: clang-9: error: unsupported option '-fsanitize=float-divide-by-zero' for target 'x86_64-unknown-linux-gnu' Also, add SanitizerMask::FloatDivideByZero to a few other masks to make -fsanitize-trap, -fsanitize-recover, -fsanitize-minimal-runtime and -fsanitize-coverage work. Reviewed By: rsmith, vitalybuka Differential Revision: https://reviews.llvm.org/D64317 llvm-svn: 365587
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +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
* [asan] Add gcc 8's driver option -fsanitize=pointer-compare and ↵Pierre Gousseau2019-04-121-0/+11
| | | | | | | | | | | | -fsanitize=pointer-substract. Disabled by default as this is still an experimental feature. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D59221 llvm-svn: 358285
* [Driver] Enable -fsanitize-address-globals-dead-stripping by default on PS4.Pierre Gousseau2019-04-021-0/+1
| | | | | | | | | | Can be safely enabled on PS4. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D59815 llvm-svn: 357480
* Remove esan.Nico Weber2019-03-111-56/+0
| | | | | | | | | | | It hasn't seen active development in years, and it hasn't reached a state where it was useful. Remove the code until someone is interested in working on it again. Differential Revision: https://reviews.llvm.org/D59133 llvm-svn: 355862
* [NetBSD] Enable additional sanitizer typesMichal Gorny2019-01-121-8/+47
| | | | | | Differential Revision: https://reviews.llvm.org/D56607 llvm-svn: 351002
* hwasan: Implement lazy thread initialization for the interceptor ABI.Peter Collingbourne2019-01-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is similar to D55986 but for threads: a process with the interceptor hwasan library loaded might have some threads started by instrumented libraries and some by uninstrumented libraries, and we need to be able to run instrumented code on the latter. The solution is to perform per-thread initialization lazily. If a function needs to access shadow memory or add itself to the per-thread ring buffer its prologue checks to see whether the value in the sanitizer TLS slot is null, and if so it calls __hwasan_thread_enter and reloads from the TLS slot. The runtime does the same thing if it needs to access this data structure. This change means that the code generator needs to know whether we are targeting the interceptor runtime, since we don't want to pay the cost of lazy initialization when targeting a platform with native hwasan support. A flag -fsanitize-hwaddress-abi={interceptor,platform} has been introduced for selecting the runtime ABI to target. The default ABI is set to interceptor since it's assumed that it will be more common that users will be compiling application code than platform code. Because we can no longer assume that the TLS slot is initialized, the pthread_create interceptor is no longer necessary, so it has been removed. Ideally, lazy initialization should only cost one instruction in the hot path, but at present the call may cause us to spill arguments to the stack, which means more instructions in the hot path (or theoretically in the cold path if the spills are moved with shrink wrapping). With an appropriately chosen calling convention for the per-thread initialization function (TODO) the hot path should always need just one instruction and the cold path should need two instructions with no spilling required. Differential Revision: https://reviews.llvm.org/D56038 llvm-svn: 350429
* [Driver][PS4] Do not implicitly link against asan or ubsan if -nostdlib or ↵Pierre Gousseau2018-12-181-0/+4
| | | | | | | | | | | | -nodefaultlibs on PS4. NFC for targets other than PS4. Respect -nostdlib and -nodefaultlibs when enabling asan or ubsan. Differential Revision: https://reviews.llvm.org/D55712 llvm-svn: 349508
* [asan] Add clang flag -fsanitize-address-use-odr-indicatorVitaly Buka2018-12-051-0/+18
| | | | | | | | | | Reviewers: eugenis, m.ostapenko, ygribov Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D55157 llvm-svn: 348327
* Driver: Make -fsanitize=shadow-call-stack compatible with ↵Peter Collingbourne2018-11-091-0/+4
| | | | | | | | -fsanitize-minimal-runtime. Differential Revision: https://reviews.llvm.org/D54330 llvm-svn: 346526
* Change -fsanitize-address-poison-class-member-array-new-cookie to ↵Filipe Cabecinhas2018-11-021-0/+18
| | | | | | | | | | | | | | -fsanitize-address-poison-custom-array-cookie Handle it in the driver and propagate it to cc1 Reviewers: rjmccall, kcc, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52615 llvm-svn: 346001
* [clang][ubsan] Implicit Conversion Sanitizer - integer sign change - clang partRoman Lebedev2018-10-301-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-11/+26
| | | | | | | | | | | | | | | | | | | | 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
* [MinGW] Fix passing a sanitizer lib name as dependent libMartin Storsjo2018-10-101-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D52990 llvm-svn: 344125
* [MSan] add KMSAN support to Clang driverAlexander Potapenko2018-09-071-0/+28
| | | | | | | | | | | | | | | Boilerplate code for using KMSAN instrumentation in Clang. We add a new command line flag, -fsanitize=kernel-memory, with a corresponding SanitizerKind::KernelMemory, which, along with SanitizerKind::Memory, maps to the memory_sanitizer feature. KMSAN is only supported on x86_64 Linux. It's incompatible with other sanitizers, but supports code coverage instrumentation. llvm-svn: 341641
* [ubsan] Enable -fsanitize=vptr on Apple devices and simulatorsVedant Kumar2018-08-281-0/+9
| | | | | | | | | It seems like an oversight that this check was not always enabled for on-device or device simulator targets. Differential Revision: https://reviews.llvm.org/D51239 llvm-svn: 340849
* [ADT] Normalize empty triple componentsPetr Hosek2018-08-081-1/+1
| | | | | | | | | | | | | | | | | LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
* Revert r337635 "[Driver] Sanitizer support based on runtime library presence"Reid Kleckner2018-07-311-13/+13
| | | | | | | | This change causes issues with distributed build systems, which may only have compiler binaries without any runtime libraries. See discussion about this on https://reviews.llvm.org/D15225. llvm-svn: 338444
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-301-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Driver] Sanitizer support based on runtime library presenceGeorge Karpenkov2018-07-201-13/+13
| | | | | | | | | | | | | | | The runtime libraries of sanitizers are built in compiler-rt, and Clang can be built without compiler-rt, or compiler-rt can be configured to only build certain sanitizers. The driver should provide reasonable diagnostics and not a link-time error when a runtime library is missing. This patch changes the driver for OS X to only support sanitizers of which we can find the runtime libraries. The discussion for this patch explains the rationale Differential Revision: https://reviews.llvm.org/D15225 llvm-svn: 337635
* Fix a typo/regression in r335495.John Baldwin2018-07-101-0/+6
| | | | | | | | | | | Use getTriple.isMIPS64() to detect 64-bit MIPS ABIs in FreeBSD::getSupportedSanitizers() instead of getTriple.isMIPS32(). Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D49143 llvm-svn: 336710
* [Driver] Add PPC64 as supported for ScudoKostya Kortchinsky2018-07-031-0/+2
| | | | | | | | | | | | | | | | | | Summary: Scudo works on PPC64 as is, so mark the architecture as supported for it. This will also require a change to config-ix.cmake on the compiler-rt side. Update the tests accordingly. Reviewers: eugenis, alekseyshl Reviewed By: alekseyshl Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48833 llvm-svn: 336202
* Implement CFI for indirect calls via a member function pointer.Peter Collingbourne2018-06-261-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 llvm-svn: 335569
* [Driver] Make scudo compatible with -fsanitize-minimal-runtimeKostya Kortchinsky2018-06-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the clang side of the change, there is a compiler-rt counterpart. Scudo works with UBSan using `-fsanitize=scudo,integer` for example, and to do so it embeds UBSan runtime. This makes it not compatible with the UBSan minimal runtime, but this is something we want for production purposes. The idea is to have a Scudo minimal runtime on the compiler-rt side that will not embed UBSan. This is basically the runtime that is currently in use for Fuchsia, without coverage, stacktraces or symbolization. With this, Scudo becomes compatible with `-fsanitize-minimal-runtime`. If this approach is suitable, I'll add the tests as well, otherwise I am open to other options. Reviewers: eugenis Reviewed By: eugenis Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D48373 llvm-svn: 335352
* [Driver] Add flag "--dependent-lib=..." when enabling asan or ubsan on PS4.Pierre Gousseau2018-06-061-0/+2
| | | | | | | | | | NFC for targets other than PS4. Simplify users' workflow when enabling asan or ubsan and calling the linker separately. Differential Revision: https://reviews.llvm.org/D47375 llvm-svn: 334096
* hwasan: add -fsanitize=kernel-hwaddress flagAndrey Konovalov2018-04-131-3/+26
| | | | | | | | | This patch adds -fsanitize=kernel-hwaddress flag, that essentially enables -hwasan-kernel=1 -hwasan-recover=1 -hwasan-match-all-tag=0xff. Differential Revision: https://reviews.llvm.org/D45046 llvm-svn: 330044
* Enable msan unconditionally on Linux.Evgeniy Stepanov2018-04-041-3/+0
| | | | | | | | | | | | | | | | | | Memory sanitizer compatibility are already done in MemorySanitizer::doInitialization. It verifies whether the necessary offsets exist and bails out if not. For this reason it is no good to duplicate two checks in two projects. This patch removes clang check and postpones msan compatibility validation till MemorySanitizer::doInitialization. Another reason for this patch is to allow using msan with any CPU (given compatible runtime) and custom mapping provided via the arguments added by https://reviews.llvm.org/D44926. Patch by vit9696. Differential Revision: https://reviews.llvm.org/D44927 llvm-svn: 329241
* [HWASan] Port HWASan to Linux x86-64 (clang)Alex Shlyapnikov2018-03-231-9/+6
| | | | | | | | | | | | Summary: Porting HWASan to Linux x86-64, the third of the three patches, clang part. Reviewers: eugenis Subscribers: cryptoad, cfe-commits Differential Revision: https://reviews.llvm.org/D44745 llvm-svn: 328361
* Check that ubsan is the only supported sanitizer on OpenBSDVedant Kumar2018-03-121-0/+19
| | | | | | | | Patch by David Carlier! Differential Revision: https://reviews.llvm.org/D44069 llvm-svn: 327317
* Disable tests of -fsanitize on OpenBSDKamil Rytarowski2018-03-031-6/+0
| | | | | | | | | | | | | | This causes failures on buildbots: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/tools/clang/test/Driver/fsanitize.c:18:29: error: expected string not found in input // CHECK-UNDEFINED-OPENBSD: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|pointer-overflow|float-cast-overflow|array-bounds|enum|bool|builtin|returns-nonnull-attribute|nonnull-attribute),?){18}"}} ^ <stdin>:1:1: note: scanning from here clang version 7.0.0 (trunk 326648) ^ This will be investigated. llvm-svn: 326652
* [Driver] Add SafeStack to a map of incompatible sanitizersPetr Hosek2018-02-271-5/+2
| | | | | | | | | This allows reporting an error when user tries to use SafeStack with incompatible sanitizers. Differential Revision: https://reviews.llvm.org/D43606 llvm-svn: 326151
* [Driver] Add support for mips32 and scudoSimon Dardis2018-01-251-0/+4
| | | | | | | | | | | r317337 missed that scudo is supported on MIPS32, so permit that option for MIPS32. Reviewers: cryptoad, atanasyan Differential Revision: https://reviews.llvm.org/D42416 llvm-svn: 323412
* [MSan] Enable use-after-dtor instrumentation by default.Matt Morehouse2018-01-101-1/+1
| | | | | | | | | | | | | | | | | Summary: Enable the compile-time flag -fsanitize-memory-use-after-dtor by default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1 still needs to be enabled for destructors to be poisoned. Reviewers: eugenis, vitalybuka, kcc Reviewed By: eugenis, vitalybuka Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37860 llvm-svn: 322221
* [Driver] Ensure no overlap between trapping & recoverable sanitizers. NFC.Vedant Kumar2017-12-211-0/+1
| | | | | | | This is NFC because in EmitCheck(), -fsanitize-trap=X overrides -fsanitize-recover=X. llvm-svn: 321230
* Hardware-assisted AddressSanitizer (clang part).Evgeniy Stepanov2017-12-091-0/+19
| | | | | | | | | | | | | | Summary: Driver, frontend and LLVM codegen for HWASan. A clone of ASan, basically. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D40936 llvm-svn: 320232
* [driver] Set the 'simulator' environment for Darwin when compiling forAlex Lorenz2017-12-071-4/+4
| | | | | | | | | | iOS/tvOS/watchOS simulator rdar://35135215 Differential Revision: https://reviews.llvm.org/D40682 llvm-svn: 320073
* [Driver] Add Scudo as a possible -fsanitize= optionKostya Kortchinsky2017-11-031-0/+26
| | | | | | | | | | | | | | | | | | | | | | Summary: This change adds Scudo as a possible Sanitizer option via -fsanitize=. This allows for easier static & shared linking of the Scudo library, it allows us to enforce PIE (otherwise the security of the allocator is moot), and check for incompatible Sanitizers combo. In its current form, Scudo is not compatible with any other Sanitizer, but the plan is to make it work in conjunction with UBsan (-fsanitize=scudo,undefined), which will require additional work outside of the scope of this change. Reviewers: eugenis, kcc, alekseyshl Reviewed By: eugenis, alekseyshl Subscribers: llvm-commits, srhines Differential Revision: https://reviews.llvm.org/D39334 llvm-svn: 317337
* [CFI] Add CFI-icall pointer type generalizationVlad Tsyrklevich2017-10-311-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows generalizing pointers in type signatures used for cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag. This works by 1) emitting an additional generalized type signature metadata node for functions and 2) llvm.type.test()ing for the generalized type for translation units with the flag specified. This flag is incompatible with -fsanitize-cfi-cross-dso because it would require emitting twice as many type hashes which would increase artifact size. Reviewers: pcc, eugenis Reviewed By: pcc Subscribers: kcc Differential Revision: https://reviews.llvm.org/D39358 llvm-svn: 317044
* [LSan] Enable -fsanitize=leak for PPC64 Linux.Alex Shlyapnikov2017-10-261-0/+3
| | | | | | | | | | | | Summary: . Reviewers: eugenis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D39312 llvm-svn: 316636
* Enable -pie and --enable-new-dtags by default on Android.Evgeniy Stepanov2017-10-251-1/+7
| | | | | | | | | | | | | | | Summary: Also enable -no-pie on Gnu toolchain (previously available on Darwin only). Non-PIE executables won't even start on recent Android, and DT_RPATH is ignored by the loader. Reviewers: srhines, danalbert Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D38430 llvm-svn: 316606
OpenPOWER on IntegriCloud