Commit Graph

111 Commits

Author SHA1 Message Date
Kostya Serebryany 3b41971763 [sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; clang part
llvm-svn: 280044
2016-08-30 01:27:03 +00:00
Vedant Kumar 5fb00e4bd7 Revert "[Driver] Compute effective target triples once per job (NFCI)"
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
2016-07-27 23:01:55 +00:00
Vedant Kumar bf51e703cf [Driver] Compute effective target triples once per job (NFCI)
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
2016-07-18 19:56:38 +00:00
Evgeniy Stepanov aac94b1e2e Fix linking of DFSan + coverage.
Broken in r272717 because of no test coverage.

llvm-svn: 272853
2016-06-15 23:05:21 +00:00
Evgeniy Stepanov 5c063c108a Fix sanitizer coverage support in the win32 driver.
--dependent-lib arguments for the sanitizer libraries must be emitted when
coverage is enabled w/o any sanitizers.

llvm-svn: 272735
2016-06-14 23:21:19 +00:00
Evgeniy Stepanov 5b49eb42c5 [sanitizer] Allow sanitize coverage w/o sanitizers.
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
2016-06-14 21:33:40 +00:00
Vitaly Buka 9d4eb6f389 [asan] Added -fsanitize-address-use-after-scope flag
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
2016-06-02 00:24:20 +00:00
Kostya Serebryany ceb1add630 document -f[no-]sanitize-recover=all and mention it in warning messages
llvm-svn: 268540
2016-05-04 20:21:47 +00:00
Peter Collingbourne 3afb266886 Re-apply r267784, r267824 and r267830.
I have updated the compiler-rt tests.

llvm-svn: 267903
2016-04-28 17:09:37 +00:00
Benjamin Kramer 5556a5cf3b Revert r267784, r267824 and r267830.
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
2016-04-28 12:14:47 +00:00
Peter Collingbourne f10237b689 Driver: only produce CFI -fvisibility= error when compiling.
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
2016-04-28 00:18:30 +00:00
Peter Collingbourne a8b2f7c0d7 Rework interface for bitset-using features to use a notion of LTO visibility.
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
2016-04-27 20:39:53 +00:00
Derek Bruening 256c2e14c7 [esan] EfficiencySanitizer driver flags
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
2016-04-21 21:32:04 +00:00
Kostya Serebryany f5b25f83e3 [sanitizer-coverage] make sure coverage flags are not passed to clang if the driver thinks they are unused
llvm-svn: 266673
2016-04-18 21:30:17 +00:00
Ed Schouten fc79d2ca42 Enable the SafeStack sanitizer on CloudABI by default.
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
2016-03-29 21:13:53 +00:00
Kostya Serebryany 578787ad30 [libFuzzer] allow -fsanitize-coverage=0 (disables all coverage)
llvm-svn: 262503
2016-03-02 19:16:54 +00:00
Nico Weber 4152f522aa Make deprecation message for -fsanitize-coverage= with numeric argument friendlier.
http://reviews.llvm.org/D17397

llvm-svn: 261247
2016-02-18 19:32:54 +00:00
Kostya Serebryany 52e86493e3 [sanitizer-coverage] allow -fsanitize-coverage=trace-pc w/o any other sanitizer and w/o ...=[func,bb,edge]. This makes this syntax a superset of the GCC's syntax
llvm-svn: 261182
2016-02-18 00:49:23 +00:00
Kostya Serebryany 8e3061b865 [sanitizer-coverage] add a deprecation warning for -fsanitize-coverage=[1234]
llvm-svn: 261178
2016-02-17 23:57:17 +00:00
Kostya Serebryany d4590c7304 [sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar 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
2016-02-17 21:34:43 +00:00
Peter Collingbourne dc13453128 Introduce -fsanitize-stats flag.
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
2016-01-16 00:31:22 +00:00
Peter Collingbourne f7e62096ff Driver: Remove SanitizerArgs::clear() function and SanitizerSet ctor,
replace with in-class initializers.

llvm-svn: 257739
2016-01-14 02:49:51 +00:00
Evgeniy Stepanov e3fb51cf5a [cfi] Exclude ubsan runtime library from non-diag CFI builds (driver changes).
Split the CFI runtime in two: cfi and cfi_diag. The latter includes
UBSan runtime to allow printing diagnostics.

llvm-svn: 255736
2015-12-16 00:38:42 +00:00
Evgeniy Stepanov fd6f92d5cb Cross-DSO control flow integrity (Clang part).
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
2015-12-15 23:00:20 +00:00
Yury Gribov 5bfeca1201 [ASan] Allow -fsanitize-recover=address.
Differential Revision: http://reviews.llvm.org/D14243

llvm-svn: 252721
2015-11-11 10:45:48 +00:00
Evgeniy Stepanov 71554fe21b MemorySanitizer does not require PIE.
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
2015-10-21 21:28:49 +00:00
Evgeniy Stepanov 76f853397a Revert "MemorySanitizer does not require PIE."
It actually does require PIE on some targets.

llvm-svn: 250944
2015-10-21 20:47:00 +00:00
Evgeniy Stepanov dccad5b9c3 MemorySanitizer does not require PIE.
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
2015-10-21 20:20:03 +00:00
Teresa Johnson 945bc50f21 Recommit "Clang support for -flto=thin."
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
2015-10-15 20:35:53 +00:00
Teresa Johnson fca505c674 Revert "Clang support for -flto=thin." (bot failures)
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
2015-10-15 13:41:51 +00:00
Teresa Johnson 31b2354929 Clang support for -flto=thin.
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
2015-10-15 13:08:13 +00:00
Evgeniy Stepanov 14deb7b65f Use Triple.isAndroid() where possible.
llvm-svn: 249751
2015-10-08 21:21:44 +00:00
Vasileios Kalintiris 447e35701a Allow a ToolChain to compute the path of a compiler-rt's component.
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
2015-10-01 16:54:58 +00:00
Saleem Abdulrasool d44901f21b Driver: support ARM/HF on a single toolchain
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
2015-09-26 03:26:44 +00:00
Ivan Krasin 4c3f237edb Do not include default sanitizer blacklists into -M/-MM/-MD/-MMD output.
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
2015-09-02 20:02:38 +00:00
Peter Collingbourne 6fccf95aad CodeGen: Improve CFI type blacklisting mechanism.
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
2015-07-15 12:15:56 +00:00
Evgeniy Stepanov 45be9e0d24 Add an experimental flag -fsanitize-memory-use-after-dtor.
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
2015-07-10 20:07:16 +00:00
Peter Collingbourne 4bdceaa4de Driver: enable support for -fsanitize=cfi on Windows.
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
2015-07-08 21:08:05 +00:00
Peter Collingbourne 581f438f4c Driver: add support for linking the UBSan runtime library on Windows.
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
2015-07-02 01:48:12 +00:00
Alexey Samsonov 9b87309a91 [CFI] Diagnose when we CFI in diagnostic mode is unavailable on a toolchain.
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
2015-06-25 23:14:32 +00:00
Alexey Samsonov 7f2a0d2c04 [Sanitizers] Provide better diagnostic for sanitizers unsupported for target 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
2015-06-19 21:36:47 +00:00
Alexey Samsonov 907880edd9 [CFI] Require -flto instead of implying it.
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
2015-06-19 19:57:46 +00:00
Alexander Potapenko b9b73ef906 [ASan] Initial support for Kernel AddressSanitizer
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
2015-06-19 12:19:07 +00:00
Peter Collingbourne 6708c4a176 Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.
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
2015-06-19 01:51:54 +00:00
Peter Collingbourne 9881b78b53 Introduce -fsanitize-trap= flag.
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
2015-06-18 23:59:22 +00:00
Alexey Samsonov 9bc2ad5e6c Revert "[Sanitizers] Provide better diagnostic for sanitizers unsupported 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
2015-06-17 22:27:32 +00:00
Alexey Samsonov 9170efdc0d [Sanitizers] Provide better diagnostic for sanitizers unsupported for target 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
2015-06-17 22:07:28 +00:00
Alexey Samsonov de0aff3e91 [Driver] Improve unused-argument diagnostic for extra sanitizer features.
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
2015-05-21 01:07:52 +00:00
Peter Collingbourne bf59c34bfd Move sanitizer parser and group expander from Driver to Basic.
No functional change.

Differential Revision: http://reviews.llvm.org/D9621

llvm-svn: 237056
2015-05-11 21:39:20 +00:00
Peter Collingbourne 3eea677f3a Unify sanitizer kind representation between the driver and the rest of the compiler.
No functional change.

Differential Revision: http://reviews.llvm.org/D9618

llvm-svn: 237055
2015-05-11 21:39:14 +00:00