maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/fsanitize.c

327 lines
29 KiB
C
Raw Normal View History

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-19 07:59:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-trap=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-trap=undefined -fno-sanitize-trap=signed-integer-overflow %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-undefined-trap-on-error %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
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-18 06:27:32 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
// RUN: %clang -target x86_64-linux-gnu -fsanitize-undefined-trap-on-error -fsanitize=undefined-trap %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
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-19 07:59:22 +08:00
// CHECK-UNDEFINED-TRAP: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute|function),?){18}"}}
// CHECK-UNDEFINED-TRAP: "-fsanitize-trap=alignment,array-bounds,bool,enum,float-cast-overflow,float-divide-by-zero,function,integer-divide-by-zero,nonnull-attribute,null,object-size,return,returns-nonnull-attribute,shift-base,shift-exponent,signed-integer-overflow,unreachable,vla-bound"
// CHECK-UNDEFINED-TRAP2: "-fsanitize-trap=alignment,array-bounds,bool,enum,float-cast-overflow,float-divide-by-zero,function,integer-divide-by-zero,nonnull-attribute,null,object-size,return,returns-nonnull-attribute,shift-base,shift-exponent,unreachable,vla-bound"
[ubsan] Implement the -fcatch-undefined-behavior flag using a trapping implementation; this is much more inline with the original implementation (i.e., pre-ubsan) and does not require run-time library support. The trapping implementation can be invoked using either '-fcatch-undefined-behavior' or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed. llvm-svn: 173848
2013-01-30 07:31:22 +08:00
Add -fsanitize=<sanitizers> argument to driver and frontend, and add -fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the various UBSan checks to be enabled and disabled separately. Right now, the different modes can't be combined, but the intention is that combining UBSan and the other sanitizers will be permitted in the near future. Currently, the UBSan checks will all be enabled if any of them is; that will be fixed by the next patch. llvm-svn: 167411
2012-11-06 06:04:41 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED
[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -fsanitize=shift-exponent. This is a recommit of r231150, reverted in r231409. Turns out that -fsanitize=shift-base check implementation only works if the shift exponent is valid, otherwise it contains undefined behavior itself. Make sure we check that exponent is valid before we proceed to check the base. Make sure that we actually report invalid values of base or exponent if -fsanitize=shift-base or -fsanitize=shift-exponent is specified, respectively. llvm-svn: 231711
2015-03-10 05:50:19 +08:00
// CHECK-UNDEFINED: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|function|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|vptr|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){19}"}}
Add -fsanitize=<sanitizers> argument to driver and frontend, and add -fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the various UBSan checks to be enabled and disabled separately. Right now, the different modes can't be combined, but the intention is that combining UBSan and the other sanitizers will be permitted in the near future. Currently, the UBSan checks will all be enabled if any of them is; that will be fixed by the next patch. llvm-svn: 167411
2012-11-06 06:04:41 +08:00
SanitizerArgs: add ability to filter/diagnose unsupported sanitizers. The thread, memory, dataflow and function sanitizers are now diagnosed if enabled explicitly on an unsupported platform. Unsupported sanitizers which are enabled implicitly (as part of a larger group) are silently disabled. As a side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain. Differential Revision: http://llvm-reviews.chandlerc.com/D1990 llvm-svn: 193875
2013-11-02 02:16:25 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-DARWIN
[UBSan] Allow to use -fsanitize=vptr only on Mac OS 10.9+ See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this is necessary. llvm-svn: 240618
2015-06-25 08:58:02 +08:00
// CHECK-UNDEFINED-DARWIN: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
SanitizerArgs: add ability to filter/diagnose unsupported sanitizers. The thread, memory, dataflow and function sanitizers are now diagnosed if enabled explicitly on an unsupported platform. Unsupported sanitizers which are enabled implicitly (as part of a larger group) are silently disabled. As a side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain. Differential Revision: http://llvm-reviews.chandlerc.com/D1990 llvm-svn: 193875
2013-11-02 02:16:25 +08:00
[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-20 05:36:47 +08:00
// RUN: %clang -target i386-unknown-openbsd -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-OPENBSD
// CHECK-UNDEFINED-OPENBSD: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
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 09:48:12 +08:00
// RUN: %clang -target i386-pc-win32 -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN --check-prefix=CHECK-UNDEFINED-WIN32
// RUN: %clang -target i386-pc-win32 -fsanitize=undefined -x c++ %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN --check-prefix=CHECK-UNDEFINED-WIN32 --check-prefix=CHECK-UNDEFINED-WIN-CXX
// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN --check-prefix=CHECK-UNDEFINED-WIN64
// RUN: %clang -target x86_64-pc-win32 -fsanitize=undefined -x c++ %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-WIN --check-prefix=CHECK-UNDEFINED-WIN64 --check-prefix=CHECK-UNDEFINED-WIN-CXX
// CHECK-UNDEFINED-WIN: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
// CHECK-UNDEFINED-WIN32-SAME: "--dependent-lib={{[^"]*}}ubsan_standalone-i386.lib"
// CHECK-UNDEFINED-WIN64-SAME: "--dependent-lib={{[^"]*}}ubsan_standalone-x86_64.lib"
// CHECK-UNDEFINED-WIN-CXX-SAME: "--dependent-lib={{[^"]*}}ubsan_standalone_cxx{{[^"]*}}.lib"
Add -fsanitize=integer for reporting suspicious integer behaviors. Introduces new sanitizer "unsigned-integer-overflow". llvm-svn: 168701
2012-11-27 23:01:55 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=integer %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-INTEGER
[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -fsanitize=shift-exponent. This is a recommit of r231150, reverted in r231409. Turns out that -fsanitize=shift-base check implementation only works if the shift exponent is valid, otherwise it contains undefined behavior itself. Make sure we check that exponent is valid before we proceed to check the base. Make sure that we actually report invalid values of base or exponent if -fsanitize=shift-base or -fsanitize=shift-exponent is specified, respectively. llvm-svn: 231711
2015-03-10 05:50:19 +08:00
// CHECK-INTEGER: "-fsanitize={{((signed-integer-overflow|unsigned-integer-overflow|integer-divide-by-zero|shift-base|shift-exponent),?){5}"}}
Add -fsanitize=integer for reporting suspicious integer behaviors. Introduces new sanitizer "unsigned-integer-overflow". llvm-svn: 168701
2012-11-27 23:01:55 +08:00
Kill deprecated -fbounds-checking flag llvm-svn: 204436
2014-03-21 15:15:47 +08:00
// RUN: %clang -fsanitize=bounds -### -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix=CHECK-BOUNDS
// CHECK-BOUNDS: "-fsanitize={{((array-bounds|local-bounds),?){2}"}}
Allow to disable all sanitizers with "-fno-sanitize=all" option. Summary: This patch adds "all" sanitizer group. A shortcut "-fno-sanitize=all" can be used to disable all sanitizers for a given source file. "-fsanitize=all" option makes no sense, and will produce an error. This group can also be useful when we add "-fsanitize-recover=<list>" options (patch in http://reviews.llvm.org/D6302), as it would allow to conveniently enable/disable recovery for all specified sanitizers. Test Plan: regression test suite Reviewers: kcc, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6733 llvm-svn: 224596
2014-12-20 02:41:43 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=all %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSANITIZE-ALL
// CHECK-FSANITIZE-ALL: error: unsupported argument 'all' to option 'fsanitize='
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address,undefined -fno-sanitize=all -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FNO-SANITIZE-ALL
// CHECK-FNO-SANITIZE-ALL: "-fsanitize=thread"
Kill -faddress-sanitizer, -fthread-sanitizer and -fcatch-undefined-behavior flags. These flags are deprecated since at least Clang 3.3. Users should instead use -fsanitize= with appropriate values. llvm-svn: 204330
2014-03-20 18:48:29 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=thread,undefined -fno-sanitize=thread -fno-sanitize=float-cast-overflow,vptr,bool,enum %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-PARTIAL-UNDEFINED
[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -fsanitize=shift-exponent. This is a recommit of r231150, reverted in r231409. Turns out that -fsanitize=shift-base check implementation only works if the shift exponent is valid, otherwise it contains undefined behavior itself. Make sure we check that exponent is valid before we proceed to check the base. Make sure that we actually report invalid values of base or exponent if -fsanitize=shift-base or -fsanitize=shift-exponent is specified, respectively. llvm-svn: 231711
2015-03-10 05:50:19 +08:00
// CHECK-PARTIAL-UNDEFINED: "-fsanitize={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|function|shift-base|shift-exponent|unreachable|return|vla-bound|alignment|null|object-size|array-bounds|returns-nonnull-attribute|nonnull-attribute),?){15}"}}
// RUN: %clang -target x86_64-linux-gnu -fsanitize=shift -fno-sanitize=shift-base %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSANITIZE-SHIFT-PARTIAL
// CHECK-FSANITIZE-SHIFT-PARTIAL: "-fsanitize=shift-exponent"
Add -fsanitize=<sanitizers> argument to driver and frontend, and add -fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the various UBSan checks to be enabled and disabled separately. Right now, the different modes can't be combined, but the intention is that combining UBSan and the other sanitizers will be permitted in the near future. Currently, the UBSan checks will all be enabled if any of them is; that will be fixed by the next patch. llvm-svn: 167411
2012-11-06 06:04:41 +08:00
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-19 07:59:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=vptr -fsanitize-trap=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-VPTR-TRAP-UNDEF
// RUN: %clang -target x86_64-linux-gnu -fsanitize=vptr -fsanitize-undefined-trap-on-error %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-VPTR-TRAP-UNDEF
// CHECK-VPTR-TRAP-UNDEF: error: invalid argument '-fsanitize=vptr' not allowed with '-fsanitize-trap=undefined'
[ubsan] Implement the -fcatch-undefined-behavior flag using a trapping implementation; this is much more inline with the original implementation (i.e., pre-ubsan) and does not require run-time library support. The trapping implementation can be invoked using either '-fcatch-undefined-behavior' or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed. llvm-svn: 173848
2013-01-30 07:31:22 +08:00
Switch to using -### as mentioned by chandlerc. llvm-svn: 169089
2012-12-01 21:07:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=vptr -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-VPTR-NO-RTTI
Per discussion on cfe-commits, treat -faddress-sanitizer, -fno-address-sanitizer, -fthread-sanitizer, -fno-thread-sanitizer, and -fcatch-undefined-behavior as deprecated: produce a warning if they are used pointing to the corresponding -fsanitize= option. In passing add the missing '-' to some diagnostics. llvm-svn: 167429
2012-11-06 09:12:02 +08:00
// CHECK-VPTR-NO-RTTI: '-fsanitize=vptr' not allowed with '-fno-rtti'
Add -fsanitize=<sanitizers> argument to driver and frontend, and add -fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the various UBSan checks to be enabled and disabled separately. Right now, the different modes can't be combined, but the intention is that combining UBSan and the other sanitizers will be permitted in the near future. Currently, the UBSan checks will all be enabled if any of them is; that will be fixed by the next patch. llvm-svn: 167411
2012-11-06 06:04:41 +08:00
Improve our handling of rtti/sanitize=vptr/sanitize=undefined This patch removes the huge blob of code that is dealing with rtti/exceptions/sanitizers and replaces it with: A ToolChain function which, for a given set of Args, figures out if rtti should be: - enabled - disabled implicitly - disabled explicitly A change in the way SanitizerArgs figures out what sanitizers to enable (or if it should error out, or warn); And a check for exceptions/rtti interaction inside addExceptionArgs. The RTTIMode algorithm is: - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly; - If -frtti was passed or we're not targetting the PS4, rtti is enabled; - If -fexceptions or -fcxx-exceptions was passed and we're targetting the PS4, rtti was enabled implicitly; - If we're targetting the PS4, rtti is disabled implicitly; - Otherwise, rtti is enabled; Since the only flag needed to pass to -cc1 is -fno-rtti if we want to disable it, there's no problem in saying rtti is enabled if we're compiling C code, so we don't look at the input file type. addExceptionArgs now looks at the RTTIMode and warns that rtti is being enabled implicitly if targetting the PS4 and exceptions are on. It also errors out if, targetting the PS4, -fno-rtti was passed, and exceptions were turned on. SanitizerArgs now errors out if rtti was disabled explicitly and the vptr sanitizer was enabled implicitly, but just turns off vptr if rtti is disabled but -fsanitize=undefined was passed. Also fixed tests, removed duplicate name from addExceptionArgs comment, and added one or two surrounding lines when running clang-format. This changes test/Driver/fsanitize.c to make it not expect a warning when passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on. Removed all users and definition of SanitizerArgs::sanitizesVptr(). Reviewers: samsonov Subscribers: llvm-commits, samsonov, rsmith Differential Revision: http://reviews.llvm.org/D7525 llvm-svn: 229801
2015-02-19 09:04:49 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-NO-RTTI
// CHECK-UNDEFINED-NO-RTTI-NOT: vptr
Switch to using -### as mentioned by chandlerc. llvm-svn: 169089
2012-12-01 21:07:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address,thread -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANT
Add -fsanitize=<sanitizers> argument to driver and frontend, and add -fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the various UBSan checks to be enabled and disabled separately. Right now, the different modes can't be combined, but the intention is that combining UBSan and the other sanitizers will be permitted in the near future. Currently, the UBSan checks will all be enabled if any of them is; that will be fixed by the next patch. llvm-svn: 167411
2012-11-06 06:04:41 +08:00
// CHECK-SANA-SANT: '-fsanitize=address' not allowed with '-fsanitize=thread'
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address,memory -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANM
Reuse an existing diagnostic for tsan/msan needing -pie error. Add a diagnosting for -fsanitize=memory conflicting with other sanitizers. Extend tests. llvm-svn: 169380
2012-12-05 21:37:12 +08:00
// CHECK-SANA-SANM: '-fsanitize=address' not allowed with '-fsanitize=memory'
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=thread,memory -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANT-SANM
Reuse an existing diagnostic for tsan/msan needing -pie error. Add a diagnosting for -fsanitize=memory conflicting with other sanitizers. Extend tests. llvm-svn: 169380
2012-12-05 21:37:12 +08:00
// CHECK-SANT-SANM: '-fsanitize=thread' not allowed with '-fsanitize=memory'
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory,thread -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANM-SANT
Reuse an existing diagnostic for tsan/msan needing -pie error. Add a diagnosting for -fsanitize=memory conflicting with other sanitizers. Extend tests. llvm-svn: 169380
2012-12-05 21:37:12 +08:00
// CHECK-SANM-SANT: '-fsanitize=thread' not allowed with '-fsanitize=memory'
Add -fsanitize=leak to driver options. If -fsanitize=leak is specified, link the program with the LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified, because AddressSanitizer has this functionality built in. llvm-svn: 182729
2013-05-27 19:17:01 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak,thread -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL-SANT
// CHECK-SANL-SANT: '-fsanitize=leak' not allowed with '-fsanitize=thread'
// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak,memory -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL-SANM
// CHECK-SANL-SANM: '-fsanitize=leak' not allowed with '-fsanitize=memory'
[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 20:19:07 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=kernel-address,thread -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANKA-SANT
// CHECK-SANKA-SANT: '-fsanitize=kernel-address' not allowed with '-fsanitize=thread'
// RUN: %clang -target x86_64-linux-gnu -fsanitize=kernel-address,memory -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANKA-SANM
// CHECK-SANKA-SANM: '-fsanitize=kernel-address' not allowed with '-fsanitize=memory'
// RUN: %clang -target x86_64-linux-gnu -fsanitize=kernel-address,address -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANKA-SANA
// CHECK-SANKA-SANA: '-fsanitize=kernel-address' not allowed with '-fsanitize=address'
// RUN: %clang -target x86_64-linux-gnu -fsanitize=kernel-address,leak -pie -fno-rtti %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANKA-SANL
// CHECK-SANKA-SANL: '-fsanitize=kernel-address' not allowed with '-fsanitize=leak'
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ONLY-TRACK-ORIGINS
// CHECK-ONLY-TRACK-ORIGINS: warning: argument unused during compilation: '-fsanitize-memory-track-origins'
[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 09:07:52 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fno-sanitize=memory -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-DISABLED-MSAN
// CHECK-TRACK-ORIGINS-DISABLED-MSAN-NOT: warning: argument unused
Fix uninitialized bool flag access in SanitizerArgs parser llvm-svn: 172605
2013-01-16 19:34:36 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-EXTRA-TRACK-ORIGINS
// CHECK-NO-EXTRA-TRACK-ORIGINS-NOT: "-fsanitize-memory-track-origins"
Switch to using -### as mentioned by chandlerc. llvm-svn: 169089
2012-12-01 21:07:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize=alignment -fsanitize=vptr -fno-sanitize=vptr %s -### 2>&1
Remove restriction on combining ubsan with asan or tsan. This has worked for a while. llvm-svn: 169066
2012-12-01 09:02:45 +08:00
// OK
Refactor -fsanitize, -f*-sanitizer arguments parsing. Provide a more careful diagnostic for invalid sets of sanitizers llvm-svn: 168794
2012-11-29 01:34:24 +08:00
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -pie %s -### 2>&1
// OK
[msan] Change track-origins default mode from 1 to 2. Change -fsanitize-memory-track-origins to be equivalent to -fsanitize-memory-track-origins=2. Track-origins=2 provides a lot more detailed reports at the cost of some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on SPEC2006). llvm-svn: 230644
2015-02-26 23:59:30 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
[msan] -fsanitize-memory-track-origins=[level] flag and docs. This change turns -fsanitize-memory-track-origins into -fsanitize-memory-track-origins=[level] flag (keeping the old one for compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly detailed). See docs (part of this patch) for more info. llvm-svn: 204346
2014-03-20 22:58:36 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=1 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-1
[msan] Change track-origins default mode from 1 to 2. Change -fsanitize-memory-track-origins to be equivalent to -fsanitize-memory-track-origins=2. Track-origins=2 provides a lot more detailed reports at the cost of some additional slowdown (ranging from none to, sometimes, 3x; ~3% average on SPEC2006). llvm-svn: 230644
2015-02-26 23:59:30 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=1 -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=2 -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fno-sanitize-memory-track-origins -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=0 -fsanitize-memory-track-origins=1 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-1
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=0 -fsanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
[msan] -fsanitize-memory-track-origins=[level] flag and docs. This change turns -fsanitize-memory-track-origins into -fsanitize-memory-track-origins=[level] flag (keeping the old one for compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly detailed). See docs (part of this patch) for more info. llvm-svn: 204346
2014-03-20 22:58:36 +08:00
// CHECK-TRACK-ORIGINS-1: -fsanitize-memory-track-origins=1
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fno-sanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=0 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins -fno-sanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins -fsanitize-memory-track-origins=0 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=2 -fno-sanitize-memory-track-origins -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=2 -fsanitize-memory-track-origins=0 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-TRACK-ORIGINS
// CHECK-NO-TRACK-ORIGINS-NOT: sanitize-memory-track-origins
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=2 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-2
// CHECK-TRACK-ORIGINS-2: -fsanitize-memory-track-origins=2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-track-origins=3 -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACK-ORIGINS-3
// CHECK-TRACK-ORIGINS-3: error: invalid value '3' in '-fsanitize-memory-track-origins=3'
Support -fsanitize-memory-track-origins. llvm-svn: 171020
2012-12-24 16:42:34 +08:00
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-11 04:07:16 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory -fsanitize-memory-use-after-dtor -pie %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-USE-AFTER-DTOR
// CHECK-MSAN-USE-AFTER-DTOR: -cc1{{.*}}-fsanitize-memory-use-after-dtor
Add experimental clang/driver flag -fsanitize-address-field-padding=N Summary: This change adds an experimental flag -fsanitize-address-field-padding=N (0, 1, 2) to clang and driver. With this flag ASAN will be able to detect some cases of intra-object-overflow bugs, see https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow There is no actual functionality here yet, just the flag parsing. The functionality is being reviewed at http://reviews.llvm.org/D5687 Test Plan: Build and run SPEC, LLVM Bootstrap, Chrome with this flag. Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5676 llvm-svn: 219417
2014-10-10 01:53:04 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-field-padding=0 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-0
// CHECK-ASAN-FIELD-PADDING-0-NOT: -fsanitize-address-field-padding
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-field-padding=1 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-1
// CHECK-ASAN-FIELD-PADDING-1: -fsanitize-address-field-padding=1
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-field-padding=2 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-2
// CHECK-ASAN-FIELD-PADDING-2: -fsanitize-address-field-padding=2
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-field-padding=3 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-3
// CHECK-ASAN-FIELD-PADDING-3: error: invalid value '3' in '-fsanitize-address-field-padding=3'
// RUN: %clang -target x86_64-linux-gnu -fsanitize-address-field-padding=2 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-NO-ASAN
// CHECK-ASAN-FIELD-PADDING-NO-ASAN: warning: argument unused during compilation: '-fsanitize-address-field-padding=2'
[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 09:07:52 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize-address-field-padding=2 -fsanitize=address -fno-sanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-FIELD-PADDING-DISABLED-ASAN
// CHECK-ASAN-FIELD-PADDING-DISABLED-ASAN-NOT: warning: argument unused
Add experimental clang/driver flag -fsanitize-address-field-padding=N Summary: This change adds an experimental flag -fsanitize-address-field-padding=N (0, 1, 2) to clang and driver. With this flag ASAN will be able to detect some cases of intra-object-overflow bugs, see https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow There is no actual functionality here yet, just the flag parsing. The functionality is being reviewed at http://reviews.llvm.org/D5687 Test Plan: Build and run SPEC, LLVM Bootstrap, Chrome with this flag. Reviewers: samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5676 llvm-svn: 219417
2014-10-10 01:53:04 +08:00
Switch to using -### as mentioned by chandlerc. llvm-svn: 169089
2012-12-01 21:07:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=vptr -fno-sanitize=vptr -fsanitize=undefined,address %s -### 2>&1
Remove restriction on combining ubsan with asan or tsan. This has worked for a while. llvm-svn: 169066
2012-12-01 09:02:45 +08:00
// OK
Refactor -fsanitize, -f*-sanitizer arguments parsing. Provide a more careful diagnostic for invalid sets of sanitizers llvm-svn: 168794
2012-11-29 01:34:24 +08:00
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-22 05:28:49 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PIE
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PIE
// RUN: %clang -target x86_64-unknown-freebsd -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-PIE
// RUN: %clang -target aarch64-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-PIE
// RUN: %clang -target arm-linux-androideabi -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-PIE
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PIE
// RUN: %clang -target i386-linux-gnu -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-PIE
// CHECK-NO-PIE-NOT: "-pie"
// CHECK-NO-PIE: "-mrelocation-model" "static"
// CHECK-NO-PIE-NOT: "-pie"
// CHECK-PIE: "-mrelocation-model" "pic" "-pic-level" "2" "-pie-level" "2"
// CHECK-PIE: "-pie"
[ubsan] Recover by default, use -fno-sanitize-recover to disable. llvm-svn: 171264
2012-12-31 04:53:28 +08:00
Fixup for r188058: assume hasAsanZeroBaseShadow() is false if ASan is not needed llvm-svn: 188068
2013-08-09 18:56:42 +08:00
// RUN: %clang -target arm-linux-androideabi %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ANDROID-NO-ASAN
Turn on PIC by default on Android (http://llvm-reviews.chandlerc.com/D2603) llvm-svn: 200290
2014-01-28 14:30:35 +08:00
// CHECK-ANDROID-NO-ASAN: "-mrelocation-model" "pic"
Fixup for r188058: assume hasAsanZeroBaseShadow() is false if ASan is not needed llvm-svn: 188068
2013-08-09 18:56:42 +08:00
[ASan] Allow -fsanitize-recover=address. Differential Revision: http://reviews.llvm.org/D14243 llvm-svn: 252721
2015-11-11 18:45:48 +08:00
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -### 2>&1 | FileCheck %s --check-prefix=CHECK-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fsanitize-recover -### 2>&1 | FileCheck %s --check-prefix=CHECK-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fsanitize-recover=all -### 2>&1 | FileCheck %s --check-prefix=CHECK-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fno-sanitize-recover -fsanitize-recover=undefined -### 2>&1 | FileCheck %s --check-prefix=CHECK-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fno-sanitize-recover=undefined -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fno-sanitize-recover=all -fsanitize-recover=thread -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-RECOVER-UBSAN
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fsanitize-recover=all -fno-sanitize-recover=undefined -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-RECOVER-UBSAN
// CHECK-RECOVER-UBSAN: "-fsanitize-recover={{((signed-integer-overflow|integer-divide-by-zero|float-divide-by-zero|function|shift-base|shift-exponent|vla-bound|alignment|null|vptr|object-size|float-cast-overflow|array-bounds|enum|bool|returns-nonnull-attribute|nonnull-attribute),?){17}"}}
// CHECK-NO-RECOVER-UBSAN-NOT: sanitize-recover
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
[ASan] Allow -fsanitize-recover=address. Differential Revision: http://reviews.llvm.org/D14243 llvm-svn: 252721
2015-11-11 18:45:48 +08:00
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fno-sanitize-recover=all -fsanitize-recover=object-size,shift-base -### 2>&1 | FileCheck %s --check-prefix=CHECK-PARTIAL-RECOVER
[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -fsanitize=shift-exponent. This is a recommit of r231150, reverted in r231409. Turns out that -fsanitize=shift-base check implementation only works if the shift exponent is valid, otherwise it contains undefined behavior itself. Make sure we check that exponent is valid before we proceed to check the base. Make sure that we actually report invalid values of base or exponent if -fsanitize=shift-base or -fsanitize=shift-exponent is specified, respectively. llvm-svn: 231711
2015-03-10 05:50:19 +08:00
// CHECK-PARTIAL-RECOVER: "-fsanitize-recover={{((object-size|shift-base),?){2}"}}
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
[ASan] Allow -fsanitize-recover=address. Differential Revision: http://reviews.llvm.org/D14243 llvm-svn: 252721
2015-11-11 18:45:48 +08:00
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=address -fsanitize-recover=all -### 2>&1 | FileCheck %s --check-prefix=CHECK-RECOVER-ASAN
// CHECK-RECOVER-ASAN: "-fsanitize-recover=address"
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fsanitize-recover=foobar,object-size,unreachable -### 2>&1 | FileCheck %s --check-prefix=CHECK-DIAG-RECOVER
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
// CHECK-DIAG-RECOVER: unsupported argument 'foobar' to option 'fsanitize-recover='
[ASan] Allow -fsanitize-recover=address. Differential Revision: http://reviews.llvm.org/D14243 llvm-svn: 252721
2015-11-11 18:45:48 +08:00
// CHECK-DIAG-RECOVER: unsupported argument 'unreachable' to option 'fsanitize-recover='
Add -fsanitize=leak to driver options. If -fsanitize=leak is specified, link the program with the LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified, because AddressSanitizer has this functionality built in. llvm-svn: 182729
2013-05-27 19:17:01 +08:00
Add deprecation notice for -f(no-)sanitize-recover flags. These flags should be replaced with corresponding -f(no-)sanitize-recover=<list> flags. llvm-svn: 231983
2015-03-12 07:34:25 +08:00
// RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined -fsanitize-recover -fno-sanitize-recover -### 2>&1 | FileCheck %s --check-prefix=CHECK-DEPRECATED-RECOVER
// CHECK-DEPRECATED-RECOVER: argument '-fsanitize-recover' is deprecated, use '-fsanitize-recover=undefined,integer' instead
// CHECK-DEPRECATED-RECOVER: argument '-fno-sanitize-recover' is deprecated, use '-fno-sanitize-recover=undefined,integer' instead
// CHECK-DEPRECATED-RECOVER-NOT: is deprecated
Add -fsanitize=leak to driver options. If -fsanitize=leak is specified, link the program with the LeakSanitizer runtime. Ignore this option when -fsanitize=address is specified, because AddressSanitizer has this functionality built in. llvm-svn: 182729
2013-05-27 19:17:01 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL
// CHECK-SANL: "-fsanitize=leak"
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address,leak -fno-sanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANL-NO-SANA
// CHECK-SANA-SANL-NO-SANA: "-fsanitize=leak"
Add -fno-assume-sane-operator-new when building with MSan. A workaroudn for PR16386. MSan's operator new aften has side-effects that are miscompiled without this flag. llvm-svn: 184410
2013-06-20 18:49:46 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN
// CHECK-MSAN: "-fno-assume-sane-operator-new"
Append -fno-assume-sane-operator-new in ASan builds. This should help LSan detect leaks where operator new would otherwise be optimized out. llvm-svn: 229498
2015-02-17 23:09:33 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN
// CHECK-ASAN: "-fno-assume-sane-operator-new"
Move SanitizerArgs to the clang Driver Summary: This change turns SanitizerArgs into high-level options stored in the Driver, which are parsed lazily. This fixes an issue of multiple copies of the same diagnostic message produced by sanitizer arguments parser. Reviewers: rsmith Reviewed By: rsmith CC: chandlerc, eugenis, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1341 llvm-svn: 188660
2013-08-19 17:14:21 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=zzz %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-DIAG1
// CHECK-DIAG1: unsupported argument 'zzz' to option 'fsanitize='
// CHECK-DIAG1-NOT: unsupported argument 'zzz' to option 'fsanitize='
SanitizerArgs: add ability to filter/diagnose unsupported sanitizers. The thread, memory, dataflow and function sanitizers are now diagnosed if enabled explicitly on an unsupported platform. Unsupported sanitizers which are enabled implicitly (as part of a larger group) are silently disabled. As a side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain. Differential Revision: http://llvm-reviews.chandlerc.com/D1990 llvm-svn: 193875
2013-11-02 02:16:25 +08:00
// RUN: %clang -target i686-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-X86
// CHECK-MSAN-X86: error: unsupported option '-fsanitize=memory' for target 'i686--linux-gnu'
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-DARWIN
// CHECK-MSAN-DARWIN: unsupported option '-fsanitize=memory' for target 'x86_64-apple-darwin10'
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=memory -fno-sanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-NOMSAN-DARWIN
// CHECK-MSAN-NOMSAN-DARWIN-NOT: unsupported option
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=memory -fsanitize=thread,memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-TSAN-MSAN-DARWIN
Followup test failure fix for r252310 ("[tsan] Add Clang frontend support for TSan on OS X"). llvm-svn: 252311
2015-11-06 23:20:30 +08:00
// CHECK-MSAN-TSAN-MSAN-DARWIN: unsupported option '-fsanitize=memory' for target 'x86_64-apple-darwin10'
SanitizerArgs: add ability to filter/diagnose unsupported sanitizers. The thread, memory, dataflow and function sanitizers are now diagnosed if enabled explicitly on an unsupported platform. Unsupported sanitizers which are enabled implicitly (as part of a larger group) are silently disabled. As a side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain. Differential Revision: http://llvm-reviews.chandlerc.com/D1990 llvm-svn: 193875
2013-11-02 02:16:25 +08:00
// CHECK-MSAN-TSAN-MSAN-DARWIN-NOT: unsupported option
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=thread,memory -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-MSAN-MSAN-DARWIN
// CHECK-TSAN-MSAN-MSAN-DARWIN: unsupported option '-fsanitize=memory' for target 'x86_64-apple-darwin10'
// CHECK-TSAN-MSAN-MSAN-DARWIN-NOT: unsupported option
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=function %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-DARWIN
// CHECK-FSAN-DARWIN: unsupported option '-fsanitize=function' for target 'x86_64-apple-darwin10'
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=function -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-UBSAN-DARWIN
// CHECK-FSAN-UBSAN-DARWIN: unsupported option '-fsanitize=function' for target 'x86_64-apple-darwin10'
clang-cl: Diagnose the usage of ASAN with a debug runtime library Summary: AddressSanitizer currently doesn't support this configuration, and binaries built with it will just get into an infinite loop during startup. Test Plan: Includes an automated test. Reviewers: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5764 llvm-svn: 219744
2014-10-15 07:15:44 +08:00
[UBSan] Allow to use -fsanitize=vptr only on Mac OS 10.9+ See https://llvm.org/bugs/show_bug.cgi?id=23539 for why this is necessary. llvm-svn: 240618
2015-06-25 08:58:02 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -mmacosx-version-min=10.8 -fsanitize=vptr %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-VPTR-DARWIN-OLD
// CHECK-VPTR-DARWIN-OLD: unsupported option '-fsanitize=vptr' for target 'x86_64-apple-darwin10'
// RUN: %clang -target x86_64-apple-darwin10 -mmacosx-version-min=10.9 -fsanitize=alignment,vptr %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-VPTR-DARWIN-NEW
// CHECK-VPTR-DARWIN-NEW: -fsanitize=alignment,vptr
[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-20 05:36:47 +08:00
// RUN: %clang -target armv7-apple-ios7 -miphoneos-version-min=7.0 -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-IOS
// CHECK-ASAN-IOS: unsupported option '-fsanitize=address' for target 'arm-apple-ios7'
// RUN: %clang -target i386-pc-openbsd -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-OPENBSD
// CHECK-ASAN-OPENBSD: unsupported option '-fsanitize=address' for target 'i386-pc-openbsd'
[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-20 03:57:46 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI
Driver: Support cfi-icall on all OSs when targeting x86/x86_64. llvm-svn: 247324
2015-09-11 03:18:05 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -fsanitize=cfi -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI
[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-20 03:57:46 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi-derived-cast -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-DCAST
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi-unrelated-cast -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-UCAST
// RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-nvcall -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NVCALL
// RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-vcall -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-VCALL
CFI: Introduce -fsanitize=cfi-icall flag. This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
2015-09-10 10:17:40 +08:00
// CHECK-CFI: -emit-llvm-bc{{.*}}-fsanitize=cfi-derived-cast,cfi-icall,cfi-unrelated-cast,cfi-nvcall,cfi-vcall
Implement bad cast checks using control flow integrity information. This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
2015-03-14 10:42:25 +08:00
// CHECK-CFI-DCAST: -emit-llvm-bc{{.*}}-fsanitize=cfi-derived-cast
// CHECK-CFI-UCAST: -emit-llvm-bc{{.*}}-fsanitize=cfi-unrelated-cast
Implement CFI type checks for non-virtual calls. This uses the same class metadata currently used for virtual call and cast checks. The new flag is -fsanitize=cfi-nvcall. For consistency, the -fsanitize=cfi-vptr flag has been renamed -fsanitize=cfi-vcall. Differential Revision: http://reviews.llvm.org/D8756 llvm-svn: 233874
2015-04-02 08:23:30 +08:00
// CHECK-CFI-NVCALL: -emit-llvm-bc{{.*}}-fsanitize=cfi-nvcall
// CHECK-CFI-VCALL: -emit-llvm-bc{{.*}}-fsanitize=cfi-vcall
Implement Control Flow Integrity for virtual calls. This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
2015-02-21 04:30:56 +08:00
[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-20 03:57:46 +08:00
// RUN: %clang -target x86_64-linux-gnu -flto -fsanitize=cfi-derived-cast -fno-lto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NOLTO
// CHECK-CFI-NOLTO: '-fsanitize=cfi-derived-cast' only allowed with '-flto'
CFI: Introduce -fsanitize=cfi-icall flag. This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
2015-09-10 10:17:40 +08:00
// RUN: %clang -target mips-unknown-linux -fsanitize=cfi-icall %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-ICALL-MIPS
// CHECK-CFI-ICALL-MIPS: unsupported option '-fsanitize=cfi-icall' for target 'mips-unknown-linux'
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-19 07:59:22 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize-trap=address -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-TRAP
// CHECK-ASAN-TRAP: error: unsupported argument 'address' to option '-fsanitize-trap'
[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-26 07:14:32 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -mmacosx-version-min=10.7 -flto -fsanitize=cfi-vcall -fno-sanitize-trap=cfi -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NOTRAP-OLD-MACOS
// CHECK-CFI-NOTRAP-OLD-MACOS: error: unsupported option '-fno-sanitize-trap=cfi-vcall' for target 'x86_64-apple-darwin10'
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-09 05:08:05 +08:00
// RUN: %clang -target x86_64-pc-win32 -flto -fsanitize=cfi-vcall -fno-sanitize-trap=cfi -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NOTRAP-WIN
// CHECK-CFI-NOTRAP-WIN: -emit-llvm-bc
// CHECK-CFI-NOTRAP-WIN-NOT: -fsanitize-trap=cfi
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-16 07:00:20 +08:00
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fsanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-CROSS-DSO
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NO-CROSS-DSO
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fsanitize-cfi-cross-dso -fno-sanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NO-CROSS-DSO
// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fno-sanitize-cfi-cross-dso -fsanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-CROSS-DSO
// CHECK-CFI-CROSS-DSO: -emit-llvm-bc
// CHECK-CFI-CROSS-DSO: -fsanitize-cfi-cross-dso
// CHECK-CFI-NO-CROSS-DSO: -emit-llvm-bc
// CHECK-CFI-NO-CROSS-DSO-NOT: -fsanitize-cfi-cross-dso
clang-cl: Diagnose the usage of ASAN with a debug runtime library Summary: AddressSanitizer currently doesn't support this configuration, and binaries built with it will just get into an infinite loop during startup. Test Plan: Includes an automated test. Reviewers: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5764 llvm-svn: 219744
2014-10-15 07:15:44 +08:00
// RUN: %clang_cl -fsanitize=address -c -MDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -MTd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -LDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -MD -MDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -MT -MTd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -LD -LDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// CHECK-ASAN-DEBUGRTL: error: invalid argument
// CHECK-ASAN-DEBUGRTL: not allowed with '-fsanitize=address'
// CHECK-ASAN-DEBUGRTL: note: AddressSanitizer doesn't support linking with debug runtime libraries yet
// RUN: %clang_cl -fsanitize=address -c -MT -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// RUN: %clang_cl -fsanitize=address -c -MD -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// RUN: %clang_cl -fsanitize=address -c -LD -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// RUN: %clang_cl -fsanitize=address -c -MTd -MT -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// RUN: %clang_cl -fsanitize=address -c -MDd -MD -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// RUN: %clang_cl -fsanitize=address -c -LDd -LD -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-RELEASERTL
// CHECK-ASAN-RELEASERTL-NOT: error: invalid argument
Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute This patch adds the -fsanitize=safe-stack command line argument for clang, which enables the Safe Stack protection (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of Clang. The patches make the following changes: - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang to control safe stack usage (the safe stack is disabled by default). - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be used to disable the safe stack for individual functions even when enabled globally. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6095 llvm-svn: 239762
2015-06-16 05:08:13 +08:00
// RUN: %clang -fno-sanitize=safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=NOSP
// NOSP-NOT: "-fsanitize=safe-stack"
// RUN: %clang -target x86_64-linux-gnu -fsanitize=safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=SP
// RUN: %clang -target x86_64-linux-gnu -fsanitize=address,safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=SP-ASAN
// RUN: %clang -target x86_64-linux-gnu -fstack-protector -fsanitize=safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=SP
// RUN: %clang -target x86_64-linux-gnu -fsanitize=safe-stack -fstack-protector-all -### %s 2>&1 | FileCheck %s -check-prefix=SP
Enable SafeStack on all Linux platforms. llvm-svn: 248518
2015-09-25 01:22:46 +08:00
// RUN: %clang -target arm-linux-androideabi -fsanitize=safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=SP
// RUN: %clang -target aarch64-linux-android -fsanitize=safe-stack -### %s 2>&1 | FileCheck %s -check-prefix=SP
Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute This patch adds the -fsanitize=safe-stack command line argument for clang, which enables the Safe Stack protection (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of Clang. The patches make the following changes: - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang to control safe stack usage (the safe stack is disabled by default). - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be used to disable the safe stack for individual functions even when enabled globally. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6095 llvm-svn: 239762
2015-06-16 05:08:13 +08:00
// SP-NOT: stack-protector
// SP: "-fsanitize=safe-stack"
// SP-ASAN-NOT: stack-protector
// SP-ASAN: "-fsanitize=address,safe-stack"
Teach Clang about the PPC64 memory sanitizer implementation. Summary: This is the Clang part of the PPC64 memory sanitizer implementation in D10648. Reviewers: kcc, eugenis, willschm, wschmidt, samsonov Reviewed By: samsonov Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D10650 llvm-svn: 240628
2015-06-25 18:35:19 +08:00
// RUN: %clang -target powerpc64-unknown-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-SANM
// RUN: %clang -target powerpc64le-unknown-linux-gnu -fsanitize=memory %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-SANM
// CHECK-SANM: "-fsanitize=memory"
[PS4] Add missing tests for -fsanitize=... llvm-svn: 250516
2015-10-16 23:08:01 +08:00
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=function -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-UBSAN-PS4
// CHECK-FSAN-UBSAN-PS4: unsupported option '-fsanitize=function' for target 'x86_64-scei-ps4'
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=function %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-PS4
// CHECK-FSAN-PS4: unsupported option '-fsanitize=function' for target 'x86_64-scei-ps4'
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=dataflow %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-DFSAN-PS4
// CHECK-DFSAN-PS4: unsupported option '-fsanitize=dataflow' for target 'x86_64-scei-ps4'
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=leak %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-LSAN-PS4
// CHECK-LSAN-PS4: unsupported option '-fsanitize=leak' for target 'x86_64-scei-ps4'
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=memory %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-MSAN-PS4
// CHECK-MSAN-PS4: unsupported option '-fsanitize=memory' for target 'x86_64-scei-ps4'
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=thread %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-TSAN-PS4
// CHECK-TSAN-PS4: unsupported option '-fsanitize=thread' for target 'x86_64-scei-ps4'
[PS4] Add an additional test for ASan+UBSan llvm-svn: 254723
2015-12-05 00:18:03 +08:00
// RUN: %clang -target x86_64-scei-ps4 -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-PS4
// Make sure there are no *.{o,bc} or -l passed before the ASan library.
// CHECK-ASAN-PS4-NOT: {{(\.(o|bc)"? |-l).*-lSceDbgAddressSanitizer_stub_weak}}
// CHECK-ASAN-PS4: -lSceDbgAddressSanitizer_stub_weak