summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/SanitizerArgs.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Driver: Remove SanitizerArgs::clear() function and SanitizerSet ctor,Peter Collingbourne2016-01-141-17/+0
| | | | | | replace with in-class initializers. llvm-svn: 257739
* [cfi] Exclude ubsan runtime library from non-diag CFI builds (driver changes).Evgeniy Stepanov2015-12-161-1/+5
| | | | | | | Split the CFI runtime in two: cfi and cfi_diag. The latter includes UBSan runtime to allow printing diagnostics. llvm-svn: 255736
* Cross-DSO control flow integrity (Clang part).Evgeniy Stepanov2015-12-151-1/+18
| | | | | | | | | | | | | | Clang-side cross-DSO CFI. * Adds a command line flag -f[no-]sanitize-cfi-cross-dso. * Links a runtime library when enabled. * Emits __cfi_slowpath calls is bitset test fails. * Emits extra hash-based bitsets for external CFI checks. * Sets a module flag to enable __cfi_check generation during LTO. This mode does not yet support diagnostics. llvm-svn: 255694
* [ASan] Allow -fsanitize-recover=address.Yury Gribov2015-11-111-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D14243 llvm-svn: 252721
* MemorySanitizer does not require PIE.Evgeniy Stepanov2015-10-211-6/+8
| | | | | | | | | | | | | Since r249754 MemorySanitizer should work equally well for PIE and non-PIE executables on Linux/x86_64. Beware, with this change -fsanitize=memory no longer adds implicit -fPIE -pie compiler/linker flags on Linux/x86_64. This is a re-land of r250941, limited to Linux/x86_64 + a very minor refactoring in SanitizerArgs. llvm-svn: 250949
* Revert "MemorySanitizer does not require PIE."Evgeniy Stepanov2015-10-211-1/+1
| | | | | | It actually does require PIE on some targets. llvm-svn: 250944
* MemorySanitizer does not require PIE.Evgeniy Stepanov2015-10-211-1/+1
| | | | | | | | | | Since r249754 MemorySanitizer should work equally well for PIE and non-PIE executables. Beware, with this change -fsanitize=memory no longer adds implicit -fPIE -pie compiler/linker flags, unless the target defaults to PIE. llvm-svn: 250941
* Recommit "Clang support for -flto=thin."Teresa Johnson2015-10-151-1/+1
| | | | | | | | | This recommits r250398 with fixes to the tests for bot failures. Add "-target x86_64-unknown-linux" to the clang invocations that check for the gold plugin. llvm-svn: 250455
* Revert "Clang support for -flto=thin." (bot failures)Teresa Johnson2015-10-151-1/+1
| | | | | | | | | | | Rolling this back for now since there are a couple of bot failures on the new tests I added, and I won't have a chance to look at them in detail until later this afternoon. I think the new tests need some restrictions on having the gold plugin available. This reverts commit r250398. llvm-svn: 250402
* Clang support for -flto=thin.Teresa Johnson2015-10-151-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Add clang support for -flto=thin option, which is used to set the EmitFunctionSummary code gen option on compiles. Add -flto=full as an alias to the existing -flto. Add tests to check for proper overriding of -flto variants on the command line, and convert grep tests to FileCheck. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, cfe-commits Differential Revision: http://reviews.llvm.org/D11908 llvm-svn: 250398
* Use Triple.isAndroid() where possible.Evgeniy Stepanov2015-10-081-4/+2
| | | | llvm-svn: 249751
* Allow a ToolChain to compute the path of a compiler-rt's component.Vasileios Kalintiris2015-10-011-5/+3
| | | | | | | | | | | | | | | | Summary: This patch moves getCompilerRT() from the clang::driver::tools namespace to the ToolChain class. This is needed for multilib toolchains that need to place their libraries in Clang's resource directory with a layout that is different from the default one. Reviewers: atanasyan, rsmith Subscribers: tberghammer, danalbert, srhines, cfe-commits Differential Revision: http://reviews.llvm.org/D13339 llvm-svn: 249030
* Driver: support ARM/HF on a single toolchainSaleem Abdulrasool2015-09-261-5/+6
| | | | | | | | | | | | | | | | | ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
* Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.Ivan Krasin2015-09-021-2/+11
| | | | | | | | | | | | | | | | | Summary: Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output. Introduce a frontend option -fdepfile-entry, and only insert them for the user-defined sanitizer blacklists. In frontend, grab ExtraDeps from -fdepfile-entry, instead of -fsanitize-blacklist. Reviewers: rsmith, pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12544 llvm-svn: 246700
* CodeGen: Improve CFI type blacklisting mechanism.Peter Collingbourne2015-07-151-0/+2
| | | | | | | | | | We now use the sanitizer special case list to decide which types to blacklist. We also support a special blacklist entry for types with a uuid attribute, which are generally COM types whose virtual tables are defined externally. Differential Revision: http://reviews.llvm.org/D11096 llvm-svn: 242286
* Add an experimental flag -fsanitize-memory-use-after-dtor.Evgeniy Stepanov2015-07-101-0/+7
| | | | | | | | | | | This flag will enable detection of use-after-destructor (but before memory deallocation) bugs. No actual functionality yet. https://code.google.com/p/address-sanitizer/issues/detail?id=73 Patch by Naomi Musgrave. llvm-svn: 241935
* Driver: enable support for -fsanitize=cfi on Windows.Peter Collingbourne2015-07-081-2/+6
| | | | | | | | | There are known issues, but the current implementation is good enough for the check-cfi test suite. Differential Revision: http://reviews.llvm.org/D11030 llvm-svn: 241728
* Driver: add support for linking the UBSan runtime library on Windows.Peter Collingbourne2015-07-021-2/+15
| | | | | | | | | | | | | | On Windows the user may invoke the linker directly, so we might not have an opportunity to add runtime library flags to the linker command line. Instead, instruct the code generator to embed linker directive in the object file that cause the required runtime libraries to be linked. We might also want to do something similar for ASan, but it seems to have its own special complexities which may make this infeasible. Differential Revision: http://reviews.llvm.org/D10862 llvm-svn: 241225
* [CFI] Diagnose when we CFI in diagnostic mode is unavailable on a toolchain.Alexey Samsonov2015-06-251-1/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: Namely, we must have proper C++ABI support in UBSan runtime. We don't have a good way to check for that, so just assume that C++ABI support is there whenever -fsanitize=vptr is supported (i.e. only on handful of platforms). Exact diagnostic is also tricky. It's not "cfi" that is unsupported, just the diagnostic mode. So, I suggest to report that "-fno-sanitize-trap=cfi-foobar" is incompatible with a given target toolchain. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10751 llvm-svn: 240716
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-191-29/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support and are not toolchain- or architecture-dependent. Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539). Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. This change was first submitted as r239953 and reverted in r239958. The problem was and still is in Darwin toolchains, which get the knowledge about target platform too late after initializaition, while now we require this information when ToolChain::getSanitizerArgs() is called. r240170 works around this issue. llvm-svn: 240179
* [CFI] Require -flto instead of implying it.Alexey Samsonov2015-06-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is unfortunate, but would let us land http://reviews.llvm.org/D10467, that makes ToolChains responsible for computing the set of sanitizers they support. Unfortunately, Darwin ToolChains doesn't know about actual OS they target until ToolChain::TranslateArgs() is called. In particular, it means we won't be able to construct SanitizerArgs for these ToolChains before that. This change removes SanitizerArgs::needsLTO() method, so that now ToolChain::IsUsingLTO(), which is called very early, doesn't need SanitizerArgs to implement this method. Docs and test cases are updated accordingly. See https://llvm.org/bugs/show_bug.cgi?id=23539, which describes why we start all these. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10560 llvm-svn: 240170
* [ASan] Initial support for Kernel AddressSanitizerAlexander Potapenko2015-06-191-1/+4
| | | | | | | | | This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-191-2/+6
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* Introduce -fsanitize-trap= flag.Peter Collingbourne2015-06-181-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
* Revert "[Sanitizers] Provide better diagnostic for sanitizers unsupported ↵Alexey Samsonov2015-06-171-15/+25
| | | | | | | | | for target triple." This reverts commit r239953, while I'm investigating assertion failure from http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/9994/ llvm-svn: 239958
* [Sanitizers] Provide better diagnostic for sanitizers unsupported for target ↵Alexey Samsonov2015-06-171-25/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | triple. Summary: Introduce ToolChain::getSupportedSanitizers() that would return the set of sanitizers available on given toolchain. By default, these are sanitizers which don't necessarily require runtime support (i.e. set from -fsanitize=undefined-trap). Sanitizers (ASan, DFSan, TSan, MSan etc.) which cannot function without runtime library are marked as supported only on platforms for which we actually build these runtimes. This would allow more fine-grained checks in the future: for instance, we have to restrict availability of -fsanitize=vptr to Mac OS 10.9+ (PR23539) Update test cases accrodingly: add tests for certain unsupported configurations, remove test cases for -fsanitize=vptr + PS4 integration, as we don't build the runtime for PS4 at the moment. Test Plan: regression test suite Reviewers: pcc Subscribers: cfe-commits, filcab, eugenis, thakis, kubabrecka, emaste, rsmith Differential Revision: http://reviews.llvm.org/D10467 llvm-svn: 239953
* [Driver] Improve unused-argument diagnostic for extra sanitizer features.Alexey Samsonov2015-05-211-3/+9
| | | | | | | | | | | | | | | Don't print unused-argument warning for sanitizer-specific feature flag if this sanitizer was eanbled, and later disabled in the command line. For example, now: clang -fsanitize=address -fsanitize-coverage=bb -fno-sanitize=address a.cc doesn't print warning, but clang -fsanitize-coverage=bb does. Same holds for -fsanitize-address-field-padding= and -fsanitize-memory-track-origins= flags. Fixes PR23604. llvm-svn: 237870
* Move sanitizer parser and group expander from Driver to Basic.Peter Collingbourne2015-05-111-34/+15
| | | | | | | | No functional change. Differential Revision: http://reviews.llvm.org/D9621 llvm-svn: 237056
* Unify sanitizer kind representation between the driver and the rest of the ↵Peter Collingbourne2015-05-111-125/+74
| | | | | | | | | | compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
* [SanitizerCoverage] Implement user-friendly -fsanitize-coverage= flags.Alexey Samsonov2015-05-071-15/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Possible coverage levels are: * -fsanitize-coverage=func - function-level coverage * -fsanitize-coverage=bb - basic-block-level coverage * -fsanitize-coverage=edge - edge-level coverage Extra features are: * -fsanitize-coverage=indirect-calls - coverage for indirect calls * -fsanitize-coverage=trace-bb - tracing for basic blocks * -fsanitize-coverage=trace-cmp - tracing for cmp instructions * -fsanitize-coverage=8bit-counters - frequency counters Levels and features can be combined in comma-separated list, and can be disabled by subsequent -fno-sanitize-coverage= flags, e.g.: -fsanitize-coverage=bb,trace-bb,8bit-counters -fno-sanitize-coverage=trace-bb is equivalient to: -fsanitize-coverage=bb,8bit-counters Original semantics of -fsanitize-coverage flag is preserved: * -fsanitize-coverage=0 disables the coverage * -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func * -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb * -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge * -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls Driver tries to diagnose invalid flag usage, in particular: * At most one level (func,bb,edge) must be specified. * "trace-bb" and "8bit-counters" features require some level to be specified. See test case for more examples. Test Plan: regression test suite Reviewers: kcc Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9577 llvm-svn: 236790
OpenPOWER on IntegriCloud