summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/SanitizerArgs.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [libFuzzer] add -fsanitize-coverage-pc-table to -fsanitize=fuzzerKostya Serebryany2017-08-041-1/+2
| | | | llvm-svn: 310136
* Enable AddressSanitizer for Fuchsia targetsPetr Hosek2017-08-031-4/+5
| | | | | | | | Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D35922 llvm-svn: 309999
* [UBSan] Provide default blacklist filename for UBSanHan Shen2017-08-021-0/+2
| | | | | | | | | | | | | | | | | Summary: This is to provide a default blacklist filename for UBSan. While UBSan is turned on, it's better that clang pick up a blacklist file (when exists), just as what ASan / MSan does, so we do not end up adding the "-fsanitize-blacklist" option to every command line. Reviewers: chandlerc, echristo, vsk, eugenis Reviewed By: vsk, eugenis Subscribers: vsk, eugenis, echristo, cfe-commits Differential Revision: https://reviews.llvm.org/D35849 llvm-svn: 309873
* [ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't ↵Vedant Kumar2017-08-021-7/+0
| | | | | | | | | | | | | | | | | | 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
* [sanitizer-coverage] clang flags pumbing for -fsanitize-coverage=pc-tableKostya Serebryany2017-07-281-1/+4
| | | | llvm-svn: 309338
* [ubsan] Null-check pointers in -fsanitize=vptr (PR33881)Vedant Kumar2017-07-251-0/+7
| | | | | | | | | | | | | | | | | | | 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
* [Driver] Consider -fno-sanitize=... state when filtering out ↵Petr Hosek2017-07-211-1/+1
| | | | | | | | | | | | | | | | -fsanitize-coverage=... The driver ignores -fsanitize-coverage=... flags when also given -fsanitize=... flags for sanitizer flavors that don't support the coverage runtime. This logic failed to account for subsequent -fno-sanitize=... flags that disable the sanitizer flavors that conflict with -fsanitize-coverage=... flags. Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D35603 llvm-svn: 308707
* [libFuzzer] Add Fuzzer to the list of sanitizers which support coverage.George Karpenkov2017-06-291-1/+1
| | | | | | | | | Without this change, additional coverage flags specified after -fsanitize=fuzzer would get discarded. https://reviews.llvm.org/D34794 llvm-svn: 306734
* [ubsan] Disable the object size check at -O0Vedant Kumar2017-06-231-1/+17
| | | | | | | | | | | | This check currently isn't able to diagnose any issues at -O0, not is it likely to [1]. Disabling the check at -O0 leads to substantial compile time and binary size savings. [1] [cfe-dev] Disabling ubsan's object size check at -O0 Differential Revision: https://reviews.llvm.org/D34563 llvm-svn: 306181
* [sanitizer-coverage] one more flavor of coverage: ↵Kostya Serebryany2017-06-081-3/+7
| | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. Reapplying revisions 304630, 304631, 304632, 304673, see PR33308 llvm-svn: 305026
* [sanitizer-coverage] Allow using KASAN instrumentation with sancovAlexander Potapenko2017-06-081-2/+2
| | | | llvm-svn: 304984
* Revert "[sanitizer-coverage] one more flavor of coverage: ↵Renato Golin2017-06-051-7/+3
| | | | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)" This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days. llvm-svn: 304697
* [sanitizer-coverage] one more flavor of coverage: ↵Kostya Serebryany2017-06-031-3/+7
| | | | | | -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part) llvm-svn: 304631
* [asan] A clang flag to enable ELF globals-gc.Evgeniy Stepanov2017-05-091-0/+10
| | | | | | | | | | | | This feature is subtly broken when the linker is gold 2.26 or earlier. See the following bug for details: https://sourceware.org/bugzilla/show_bug.cgi?id=19002 Since the decision needs to be made at compilation time, we can not test the linker version. The flag is off by default on ELF targets, and on otherwise. llvm-svn: 302591
* Remove unnecessary calls to MakeArgString.Evgeniy Stepanov2017-05-091-6/+6
| | | | llvm-svn: 302590
* [Driver] Don't enable -fsanitize-use-after-scope when ASan is disabledVedant Kumar2017-05-081-6/+5
| | | | | | | | | | | | When enabling any sanitizer, -fsanitize-use-after-scope is enabled by default. This doesn't actually turn ASan on, because we've been getting lucky and there are extra checks in BackendUtil that stop this from happening. However, this has been causing a behavior change: extra lifetime markers are emitted in some cases where they aren't needed or expected. llvm-svn: 302468
* [sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a ↵Kostya Serebryany2017-05-051-1/+4
| | | | | | hidden -mllvm flag. clang part. llvm-svn: 302320
* [sanitizer-coverage] add a deprecation warning to the old sanitizer-coverage ↵Kostya Serebryany2017-05-031-2/+10
| | | | | | flag combinations llvm-svn: 301994
* Flag -fsanitize=fuzzer to enable libfuzzerGeorge Karpenkov2017-04-241-0/+4
| | | | | | | | | | Previously, adding libfuzzer to a project was a multi-step procedure, involving libfuzzer compilation, linking the library, and specifying coverage flags. With this change,libfuzzer can be enabled by adding a single -fsanitize=fuzzer flag instead. llvm-svn: 301212
* [sanitizer-coverage] deprecate -fsanitize-coverage=trace-bbKostya Serebryany2017-04-191-5/+4
| | | | llvm-svn: 300767
* [sanitizer-coverage] deprecate -fsanitize-coverage=8bit-countersKostya Serebryany2017-04-191-4/+3
| | | | llvm-svn: 300744
* [sanitizer-coverage] deprecate some of the stale coverage variantsKostya Serebryany2017-04-191-27/+5
| | | | llvm-svn: 300738
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (This is a move-only refactoring patch. There are no functionality changes.) This patch splits apart the Clang driver's tool and toolchain implementation files. Each target platform toolchain is moved to its own file, along with the closest-related tools. Each target platform toolchain has separate headers and implementation files, so the hierarchy of classes is unchanged. There are some remaining shared free functions, mostly from Tools.cpp. Several of these move to their own architecture-specific files, similar to r296056. Some of them are only used by a single target platform; since the tools and toolchains are now together, some helpers now live in a platform-specific file. The balance are helpers related to manipulating argument lists, so they are now in a new file pair, CommonArgs.h and .cpp. I've tried to cluster the code logically, which is fairly straightforward for most of the target platforms and shared architectures. I think I've made reasonable choices for these, as well as the various shared helpers; but of course, I'm happy to hear feedback in the review. There are some particular things I don't like about this patch, but haven't been able to find a better overall solution. The first is the proliferation of files: there are several files that are tiny because the toolchain is not very different from its base (usually the Gnu tools/toolchain). I think this is mostly a reflection of the true complexity, though, so it may not be "fixable" in any reasonable sense. The second thing I don't like are the includes like "../Something.h". I've avoided this largely by clustering into the current file structure. However, a few of these includes remain, and in those cases it doesn't make sense to me to sink an existing file any deeper. Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30372 llvm-svn: 297250
* [sanitizers] lsan+sancov doesn't need ubsanrt (multi def error)Mike Aizatsky2016-12-081-1/+2
| | | | | | | | Reviewers: eugenis Differential Revision: https://reviews.llvm.org/D27594 llvm-svn: 289144
* Tread TSan LLVM flags to driver: add TSan controlling flags to clang.Evgeniy Stepanov2016-11-111-0/+28
| | | | | | | | | | | | | | | | | | Summary: New clang flags, all default to true: -f[no-]sanitize-thread-data-races -f[no-]sanitize-thread-stack-traces -f[no-]sanitize-thread-atomics Reviewers: dvyukov, pcc, eugenis Subscribers: pcc, cfe-commits Patch by Alex Shlyapnikov. Differential Revision: https://reviews.llvm.org/D26461 llvm-svn: 286669
* Add -fno-sanitize-address-use-after-scope flagVitaly Buka2016-10-101-7/+6
| | | | | | | | Reviewers: eugenis Differential Revision: https://reviews.llvm.org/D25453 llvm-svn: 283801
* [CUDA] Don't try to run sanitizers on NVPTX.Justin Lebar2016-09-151-0/+6
| | | | | | | | | | | | | | | | Summary: Sanitizers aren't supported on NVPTX -- don't try to run them. This lets you e.g. pass -fsanitize=address and get asan on your host code. Reviewers: kcc Subscribers: cfe-commits, tra, jhen Differential Revision: https://reviews.llvm.org/D24640 llvm-svn: 281680
* [sanitizer-coverage] add yet another flavour of coverage instrumentation: ↵Kostya Serebryany2016-09-141-2/+5
| | | | | | trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. Clang part llvm-svn: 281432
* [sanitizer-coverage] add two more modes of instrumentation: trace-div and ↵Kostya Serebryany2016-08-301-2/+8
| | | | | | trace-gep, mostly usaful for value-profile-based fuzzing; clang part llvm-svn: 280044
* Revert "[Driver] Compute effective target triples once per job (NFCI)"Vedant Kumar2016-07-271-12/+7
| | | | | | | This reverts commit r275895 in order to address some post-commit review feedback from Eric Christopher (see: the list thread for r275895). llvm-svn: 276936
* [Driver] Compute effective target triples once per job (NFCI)Vedant Kumar2016-07-181-7/+12
| | | | | | | | | | Compute an effective target triple exactly once in ConstructJob(), and then simply pass around references to it. This eliminates wasteful re-computation of effective triples (e.g in getARMFloatABI()). Differential Revision: https://reviews.llvm.org/D22290 llvm-svn: 275895
* Fix linking of DFSan + coverage.Evgeniy Stepanov2016-06-151-1/+1
| | | | | | Broken in r272717 because of no test coverage. llvm-svn: 272853
* Fix sanitizer coverage support in the win32 driver.Evgeniy Stepanov2016-06-141-22/+22
| | | | | | | --dependent-lib arguments for the sanitizer libraries must be emitted when coverage is enabled w/o any sanitizers. llvm-svn: 272735
* [sanitizer] Allow sanitize coverage w/o sanitizers.Evgeniy Stepanov2016-06-141-9/+8
| | | | | | | The reason is that this (a) seems to work just fine and (b) useful when building stuff with sanitizer+coverage, but need to exclude the sanitizer for a particular source file. llvm-svn: 272717
* [asan] Added -fsanitize-address-use-after-scope flagVitaly Buka2016-06-021-0/+11
| | | | | | | | | | | | | | | | Summary: Also emit lifetime markers for -fsanitize-address-use-after-scope. Asan uses life-time markers for use-after-scope check. PR27453 Reviewers: kcc, eugenis, aizatsky Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D20759 llvm-svn: 271451
* document -f[no-]sanitize-recover=all and mention it in warning messagesKostya Serebryany2016-05-041-2/+4
| | | | llvm-svn: 268540
* Re-apply r267784, r267824 and r267830.Peter Collingbourne2016-04-281-0/+11
| | | | | | I have updated the compiler-rt tests. llvm-svn: 267903
* Revert r267784, r267824 and r267830.Benjamin Kramer2016-04-281-11/+0
| | | | | | | | | | It makes compiler-rt tests fail if the gold plugin is enabled. Revert "Rework interface for bitset-using features to use a notion of LTO visibility." Revert "Driver: only produce CFI -fvisibility= error when compiling." Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi." llvm-svn: 267871
* Driver: only produce CFI -fvisibility= error when compiling.Peter Collingbourne2016-04-281-8/+10
| | | | | | | The -fvisibility= flag only affects compile jobs, so there's no need to error out because of it if we aren't compiling (e.g. if we are only linking). llvm-svn: 267824
* Rework interface for bitset-using features to use a notion of LTO visibility.Peter Collingbourne2016-04-271-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Bitsets, and the compiler features they rely on (vtable opt, CFI), only have visibility within the LTO'd part of the linkage unit. Therefore, only enable these features for classes with hidden LTO visibility. This notion is based on object file visibility or (on Windows) dllimport/dllexport attributes. We provide the [[clang::lto_visibility_public]] attribute to override the compiler's LTO visibility inference in cases where the class is defined in the non-LTO'd part of the linkage unit, or where the ABI supports calling classes derived from abstract base classes with hidden visibility in other linkage units (e.g. COM on Windows). If the cross-DSO CFI mode is enabled, bitset checks are emitted even for classes with public LTO visibility, as that mode uses a separate mechanism to cause bitsets to be exported. This mechanism replaces the whole-program-vtables blacklist, so remove the -fwhole-program-vtables-blacklist flag. Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the support for the special attr:uuid blacklist entry is removed. Differential Revision: http://reviews.llvm.org/D18635 llvm-svn: 267784
* [esan] EfficiencySanitizer driver flagsDerek Bruening2016-04-211-1/+10
| | | | | | | | | | | | | | | | Summary: Adds a framework to enable the instrumentation pass for the new EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's cache fragmentation tool via -fsanitize=efficiency-cache-frag. Adds appropriate tests for the new flag. Reviewers: eugenis, vitalybuka, aizatsky, filcab Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc Differential Revision: http://reviews.llvm.org/D19169 llvm-svn: 267059
* [sanitizer-coverage] make sure coverage flags are not passed to clang if the ↵Kostya Serebryany2016-04-181-0/+2
| | | | | | driver thinks they are unused llvm-svn: 266673
* Enable the SafeStack sanitizer on CloudABI by default.Ed Schouten2016-03-291-0/+3
| | | | | | | | | | | | | | | | | | | Over the last month we've been testing SafeStack extensively. As far as we know, it works perfectly fine. That why I'd like to see us having this enabled by default for CloudABI. This change introduces a getDefaultSanitizers() function that toolchains can use to specify which sanitizers are enabled by default. Once all flags are processed, only flags that had no -fno-sanitize overrides are enabled. Extend the thests for CloudABI to test both the default case and the case in which we want to explicitly disable SafeStack. Reviewed by: eugenis, pcc Differential Revision: http://reviews.llvm.org/D18505 llvm-svn: 264787
* [libFuzzer] allow -fsanitize-coverage=0 (disables all coverage)Kostya Serebryany2016-03-021-2/+1
| | | | llvm-svn: 262503
* Make deprecation message for -fsanitize-coverage= with numeric argument ↵Nico Weber2016-02-181-3/+11
| | | | | | | | friendlier. http://reviews.llvm.org/D17397 llvm-svn: 261247
* [sanitizer-coverage] allow -fsanitize-coverage=trace-pc w/o any other ↵Kostya Serebryany2016-02-181-51/+55
| | | | | | sanitizer and w/o ...=[func,bb,edge]. This makes this syntax a superset of the GCC's syntax llvm-svn: 261182
* [sanitizer-coverage] add a deprecation warning for -fsanitize-coverage=[1234]Kostya Serebryany2016-02-171-0/+2
| | | | llvm-svn: 261178
* [sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar ↵Kostya Serebryany2016-02-171-1/+9
| | | | | | to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may be able to use this flag with AFL too llvm-svn: 261159
* Introduce -fsanitize-stats flag.Peter Collingbourne2016-01-161-0/+32
| | | | | | | | | This is part of a new statistics gathering feature for the sanitizers. See clang/docs/SanitizerStats.rst for further info and docs. Differential Revision: http://reviews.llvm.org/D16175 llvm-svn: 257971
OpenPOWER on IntegriCloud