summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/SanitizerArgs.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [AArch64] Make the memtag sanitizer require the memtag extensionMomchil Velikov2019-08-131-0/+15
| | | | | | | | ... 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/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | | 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] Don't disable -fsanitizer-coverage for safe-stack or shadow-call-stackPetr Hosek2019-08-051-1/+2
| | | | | | | | | These "sanitizers" are hardened ABIs that are wholly orthogonal to the SanitizerCoverage instrumentation. Differential Revision: https://reviews.llvm.org/D65715 llvm-svn: 367799
* [Driver] Support for disabling sanitizer runtime linkingPetr Hosek2019-08-041-2/+8
| | | | | | | | | | | This change introduces a pair of -fsanitize-link-runtime and -fno-sanitize-link-runtime flags which can be used to control linking of sanitizer runtimes. This is useful in certain environments like kernels where existing runtime libraries cannot be used. Differential Revision: https://reviews.llvm.org/D65029 llvm-svn: 367794
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-1/+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
* ARM MTE stack sanitizer.Evgeniy Stepanov2019-07-151-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Driver] Add float-divide-by-zero back to supported sanitizers after ↵Fangrui Song2019-07-101-7/+9
| | | | | | | | | | | | | | | | | | 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
* [asan] Add gcc 8's driver option -fsanitize=pointer-compare and ↵Pierre Gousseau2019-04-121-0/+29
| | | | | | | | | | | | -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-15/+4
| | | | | | | | | | | 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
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-03-011-102/+146
| | | | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". This is a recommit of r354873 but with a fix for unqualified lookup error in lldb cmake build bot. Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 llvm-svn: 355190
* revert r354873 as this breaks lldb builds.Pierre Gousseau2019-02-261-146/+102
| | | | llvm-svn: 354875
* [Driver] Allow enum SanitizerOrdinal to represent more than 64 different ↵Pierre Gousseau2019-02-261-102/+146
| | | | | | | | | | | | | sanitizer checks, NFC. enum SanitizerOrdinal has reached maximum capacity, this change extends the capacity to 128 sanitizer checks. This can eventually allow us to add gcc 8's options "-fsanitize=pointer-substract" and "-fsanitize=pointer-compare". Fixes: https://llvm.org/PR39425 Differential Revision: https://reviews.llvm.org/D57914 llvm-svn: 354873
* Test commit: fix typo.Pierre Gousseau2019-01-241-1/+1
| | | | llvm-svn: 352042
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [LTO] Add option to enable LTOUnit splitting, and disable unless neededTeresa Johnson2019-01-111-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: Adds a new -f[no]split-lto-unit flag that is disabled by default to control module splitting during ThinLTO. It is automatically enabled for -fsanitize=cfi and -fwhole-program-vtables. The new EnableSplitLTOUnit codegen flag is passed down to llvm via a new module flag of the same name. Depends on D53890. Reviewers: pcc Subscribers: ormris, mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D53891 llvm-svn: 350949
* hwasan: Implement lazy thread initialization for the interceptor ABI.Peter Collingbourne2019-01-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [asan] Add clang flag -fsanitize-address-use-odr-indicatorVitaly Buka2018-12-051-0/+8
| | | | | | | | | | Reviewers: eugenis, m.ostapenko, ygribov Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D55157 llvm-svn: 348327
* Driver: SCS is compatible with every other sanitizer.Peter Collingbourne2018-11-201-4/+1
| | | | | | | | | | Because SCS relies on system-provided runtime support, we can use it together with any other sanitizer simply by linking the runtime for the other sanitizer. Differential Revision: https://reviews.llvm.org/D54735 llvm-svn: 347282
* Driver: Make -fsanitize=shadow-call-stack compatible with ↵Peter Collingbourne2018-11-091-1/+1
| | | | | | | | -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/+8
| | | | | | | | | | | | | | -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
* [MSan] add KMSAN support to Clang driverAlexander Potapenko2018-09-071-4/+7
| | | | | | | | | | | | | | | 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
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-301-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement CFI for indirect calls via a member function pointer.Peter Collingbourne2018-06-261-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Do not enable RTTI with -fexceptions, for PS4Sunil Srivastava2018-05-181-14/+11
| | | | | | | | | | | | | | | | | | | NFC for targets other than PS4. This patch is a change in behavior for PS4, in that PS4 will no longer enable RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default on PS4). RTTI will remain disabled except for types being thrown or caught. Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted, as it is for other targets. This patch removes some PS4 specific code, making the code cleaner. Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the same as the generic x86_64-linux are removed, making the test cleaner. Differential Revision: https://reviews.llvm.org/D46982 llvm-svn: 332784
* [CFI] Force LLVM to die if the implicit blacklist files cannot be found.Peter Collingbourne2018-05-071-0/+4
| | | | | | | | | | | | | | Currently LLVM CFI tries to use an implicit blacklist file, currently in /usr/lib64/clang/<version>/share. If the file is not there, LLVM happily continues, which causes CFI to add checks to files/functions that are known to fail, generating binaries that fail. This CL causes LLVM to die (I hope) if it can't find these implicit blacklist files. Patch by Caroline Tice! Differential Revision: https://reviews.llvm.org/D46403 llvm-svn: 331674
* hwasan: add -fsanitize=kernel-hwaddress flagAndrey Konovalov2018-04-131-6/+22
| | | | | | | | | 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
* AArch64: Implement support for the shadowcallstack attribute.Peter Collingbourne2018-04-041-0/+10
| | | | | | | | | | | | The implementation of shadow call stack on aarch64 is quite different to the implementation on x86_64. Instead of reserving a segment register for the shadow call stack, we reserve the platform register, x18. Any function that spills lr to sp also spills it to the shadow call stack, a pointer to which is stored in x18. Differential Revision: https://reviews.llvm.org/D45239 llvm-svn: 329236
* Add the -fsanitize=shadow-call-stack flagVlad Tsyrklevich2018-04-031-1/+4
| | | | | | | | | | | | | | | | | Summary: Add support for the -fsanitize=shadow-call-stack flag which causes clang to add ShadowCallStack attribute to functions compiled with that flag enabled. Reviewers: pcc, kcc Reviewed By: pcc, kcc Subscribers: cryptoad, cfe-commits, kcc Differential Revision: https://reviews.llvm.org/D44801 llvm-svn: 329122
* [HWASan] Port HWASan to Linux x86-64 (clang)Alex Shlyapnikov2018-03-231-1/+1
| | | | | | | | | | | | 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
* [Driver] Update the comment about incompatible sanitizersPetr Hosek2018-03-121-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D44371 llvm-svn: 327249
* [Driver] Automatically disable incompatible default sanitizersPetr Hosek2018-03-071-13/+23
| | | | | | | | | | When a sanitizer incompatible with one of the default sanitizers is explicitly enabled, automatically disable all the conflicting default sanitizers. Differential Revision: https://reviews.llvm.org/D44064 llvm-svn: 326860
* [Driver] Add SafeStack to a map of incompatible sanitizersPetr Hosek2018-02-271-1/+3
| | | | | | | | | This allows reporting an error when user tries to use SafeStack with incompatible sanitizers. Differential Revision: https://reviews.llvm.org/D43606 llvm-svn: 326151
* When multiple sanitizers are enabled (ubsan + something else), use all ↵Richard Smith2018-02-201-30/+23
| | | | | | | | | | relevant blacklists. Ideally, we'd only use the ubsan blacklist for ubsan sanitizers, and only use the other-sanitizer blacklist for its sanitizers, but this at least enables the intended suppressions. llvm-svn: 325640
* Reland "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-141-1/+1
| | | | | | | | | This is related to moving the sanitizer blacklists to share/ subdirectory. Differential Revision: https://reviews.llvm.org/D41706 llvm-svn: 322452
* Revert "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-111-1/+1
| | | | | | This reverts commit r322258: broke the dfsan build. llvm-svn: 322260
* Reland "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-111-1/+1
| | | | | | | | | This is related to moving the sanitizer blacklists to share/ subdirectory. Differential Revision: https://reviews.llvm.org/D41706 llvm-svn: 322258
* Revert "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-111-1/+1
| | | | | | This reverts commit r322233: this is breaking dfsan tests. llvm-svn: 322242
* Reland "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-101-1/+1
| | | | | | | | | This is related to moving the sanitizer blacklists to share/ subdirectory. Differential Revision: https://reviews.llvm.org/D41706 llvm-svn: 322233
* Revert "[Driver] Update default sanitizer blacklist location"Petr Hosek2018-01-101-1/+1
| | | | | | This reverts commit r322154 because it broke sanitizer bots. llvm-svn: 322155
* [Driver] Update default sanitizer blacklist locationPetr Hosek2018-01-101-1/+1
| | | | | | | | | This is related to moving the sanitizer blacklists to share/ subdirectory. Differential Revision: https://reviews.llvm.org/D41706 llvm-svn: 322154
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-281-2/+2
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* [Driver] Ensure no overlap between trapping & recoverable sanitizers. NFC.Vedant Kumar2017-12-211-0/+3
| | | | | | | 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-10/+14
| | | | | | | | | | | | | | 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
* Update a link to the old code.google.com bug trackerHans Wennborg2017-11-131-1/+1
| | | | llvm-svn: 318109
* [Driver] Add Scudo as a possible -fsanitize= optionKostya Kortchinsky2017-11-031-13/+10
| | | | | | | | | | | | | | | | | | | | | | 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/+10
| | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud