maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/asan-globals.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

85 lines
5.8 KiB
C++
Raw Normal View History

[ASan] Improve blacklisting of global variables. This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
2014-10-18 06:37:33 +08:00
// RUN: echo "int extra_global;" > %t.extra-source.cpp
[NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/ Replace filenames, variable names, check prefixes uses of blacklist with ignore list. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D113211
2021-11-17 20:40:55 +08:00
// RUN: echo "global:*ignorelisted_global*" > %t.ignorelist
// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=address -fsanitize-ignorelist=%t.ignorelist -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,ASAN
// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=kernel-address -fsanitize-ignorelist=%t.ignorelist -emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,KASAN
// The ignorelist file uses regexps, so Windows path backslashes.
// RUN: echo "src:%s" | sed -e 's/\\/\\\\/g' > %t.ignorelist-src
// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=address -fsanitize-ignorelist=%t.ignorelist-src -emit-llvm -o - %s | FileCheck %s --check-prefix=IGNORELIST-SRC
// RUN: %clang_cc1 -include %t.extra-source.cpp -fsanitize=kernel-address -fsanitize-ignorelist=%t.ignorelist-src -emit-llvm -o - %s | FileCheck %s --check-prefix=IGNORELIST-SRC
[ASan] Print exact source location of global variables in error reports. See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the original feature request. Introduce llvm.asan.globals metadata, which Clang (or any other frontend) may use to report extra information about global variables to ASan instrumentation pass in the backend. This metadata replaces llvm.asan.dynamically_initialized_globals that was used to detect init-order bugs. llvm.asan.globals contains the following data for each global: 1) source location (file/line/column info); 2) whether it is dynamically initialized; 3) whether it is blacklisted (shouldn't be instrumented). Source location data is then emitted in the binary and can be picked up by ASan runtime in case it needs to print error report involving some global. For example: 0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40 These source locations are printed even if the binary doesn't have any debug info. This is an ABI-breaking change. ASan initialization is renamed to __asan_init_v4(). Pre-built libraries compiled with older Clang will not work with the fresh runtime. llvm-svn: 212188
2014-07-03 00:54:41 +08:00
int global;
int dyn_init_global = global;
Implement no_sanitize_address for global vars llvm-svn: 284272
2016-10-15 03:55:09 +08:00
int __attribute__((no_sanitize("address"))) attributed_global;
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
int __attribute__((disable_sanitizer_instrumentation)) disable_instrumentation_global;
[NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/ Replace filenames, variable names, check prefixes uses of blacklist with ignore list. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D113211
2021-11-17 20:40:55 +08:00
int ignorelisted_global;
[ASan] Print exact source location of global variables in error reports. See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the original feature request. Introduce llvm.asan.globals metadata, which Clang (or any other frontend) may use to report extra information about global variables to ASan instrumentation pass in the backend. This metadata replaces llvm.asan.dynamically_initialized_globals that was used to detect init-order bugs. llvm.asan.globals contains the following data for each global: 1) source location (file/line/column info); 2) whether it is dynamically initialized; 3) whether it is blacklisted (shouldn't be instrumented). Source location data is then emitted in the binary and can be picked up by ASan runtime in case it needs to print error report involving some global. For example: 0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40 These source locations are printed even if the binary doesn't have any debug info. This is an ABI-breaking change. ASan initialization is renamed to __asan_init_v4(). Pre-built libraries compiled with older Clang will not work with the fresh runtime. llvm-svn: 212188
2014-07-03 00:54:41 +08:00
[ASan][Test] Split out global alias test Some platforms do not support aliases. Split the test, and pass explicit triple to avoid test failure. Reviewed By: thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D81591
2020-06-11 01:55:51 +08:00
int __attribute__((section("__DATA, __common"))) sectioned_global; // KASAN - ignore globals in a section
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
extern "C" {
[ASan][Test] Split out global alias test Some platforms do not support aliases. Split the test, and pass explicit triple to avoid test failure. Reviewed By: thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D81591
2020-06-11 01:55:51 +08:00
int __special_global; // KASAN - ignore globals with __-prefix
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
}
[ASan] Print exact source location of global variables in error reports. See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the original feature request. Introduce llvm.asan.globals metadata, which Clang (or any other frontend) may use to report extra information about global variables to ASan instrumentation pass in the backend. This metadata replaces llvm.asan.dynamically_initialized_globals that was used to detect init-order bugs. llvm.asan.globals contains the following data for each global: 1) source location (file/line/column info); 2) whether it is dynamically initialized; 3) whether it is blacklisted (shouldn't be instrumented). Source location data is then emitted in the binary and can be picked up by ASan runtime in case it needs to print error report involving some global. For example: 0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40 These source locations are printed even if the binary doesn't have any debug info. This is an ABI-breaking change. ASan initialization is renamed to __asan_init_v4(). Pre-built libraries compiled with older Clang will not work with the fresh runtime. llvm-svn: 212188
2014-07-03 00:54:41 +08:00
void func() {
static int static_var = 0;
const char *literal = "Hello, world!";
}
[sanitizer] Reduce redzone size for small size global objects Currently 1 byte global object has a ridiculous 63 bytes redzone. This patch reduces the redzone size to be less than 32 if the size of global object is less than or equal to half of 32 (the minimal size of redzone). A 12 bytes object has a 20 bytes redzone, a 20 bytes object has a 44 bytes redzone. Reviewed By: MaskRay, #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D102469
2021-05-20 10:18:49 +08:00
// ASAN: sectioned_global{{.*}} global { i32, [28 x i8] }{{.*}}, align 32
[ASan][Test] Fix expected strings for globals test The expected strings would previously not catch bugs when redzones were added when they were not actually expected. Fix by adding "global " before the type.
2020-06-11 02:20:23 +08:00
// KASAN: sectioned_global{{.*}} global i32
[sanitizer] Reduce redzone size for small size global objects Currently 1 byte global object has a ridiculous 63 bytes redzone. This patch reduces the redzone size to be less than 32 if the size of global object is less than or equal to half of 32 (the minimal size of redzone). A 12 bytes object has a 20 bytes redzone, a 20 bytes object has a 44 bytes redzone. Reviewed By: MaskRay, #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D102469
2021-05-20 10:18:49 +08:00
// ASAN: @__special_global{{.*}} global { i32, [28 x i8] }{{.*}}, align 32
[ASan][Test] Fix expected strings for globals test The expected strings would previously not catch bugs when redzones were added when they were not actually expected. Fix by adding "global " before the type.
2020-06-11 02:20:23 +08:00
// KASAN: @__special_global{{.*}} global i32
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module. Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.) Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame. This patch * sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute. The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics. Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc. Differential Revision: https://reviews.llvm.org/D100251
2021-04-22 06:58:20 +08:00
/// Without -fasynchronous-unwind-tables, ctor and dtor get the uwtable attribute.
// CHECK-LABEL: define internal void @asan.module_ctor() #[[#ATTR:]] {
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// ASAN-NEXT: call void @__asan_init
// ASAN-NEXT: call void @__asan_version_mismatch_check
// KASAN-NOT: call void @__asan_init
// KASAN-NOT: call void @__asan_version_mismatch_check
[ASan][Test] Split out global alias test Some platforms do not support aliases. Split the test, and pass explicit triple to avoid test failure. Reviewed By: thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D81591
2020-06-11 01:55:51 +08:00
// ASAN-NEXT: call void @__asan_register_globals({{.*}}, i{{32|64}} 7)
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// KASAN-NEXT: call void @__asan_register_globals({{.*}}, i{{32|64}} 5)
// CHECK-NEXT: ret void
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module. Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.) Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame. This patch * sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute. The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics. Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc. Differential Revision: https://reviews.llvm.org/D100251
2021-04-22 06:58:20 +08:00
// CHECK: define internal void @asan.module_dtor() #[[#ATTR]] {
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// CHECK-NEXT: call void @__asan_unregister_globals
// CHECK-NEXT: ret void
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module. Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.) Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame. This patch * sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute. The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics. Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc. Differential Revision: https://reviews.llvm.org/D100251
2021-04-22 06:58:20 +08:00
// CHECK: attributes #[[#ATTR]] = { nounwind }
/// If -fasynchronous-unwind-tables, set the module flag "uwtable". ctor/dtor
/// will thus get the uwtable attribute.
Fix -fno-unwind-tables -fasynchronous-unwind-tables to emit unwind tables This matches GCC. Change the CC1 option to encode the unwind table level (1: needed by exceptions, 2: asynchronous) so that we can support two modes in the future.
2021-09-24 07:15:40 +08:00
// RUN: %clang_cc1 -emit-llvm -fsanitize=address -funwind-tables=2 -o - %s | FileCheck %s --check-prefixes=UWTABLE
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module. Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.) Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame. This patch * sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute. The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics. Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc. Differential Revision: https://reviews.llvm.org/D100251
2021-04-22 06:58:20 +08:00
// UWTABLE: define internal void @asan.module_dtor() #[[#ATTR:]] {
// UWTABLE: attributes #[[#ATTR]] = { nounwind uwtable }
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 21:41:34 +08:00
// UWTABLE: ![[#]] = !{i32 7, !"uwtable", i32 2}
[IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables On ELF targets, if a function has uwtable or personality, or does not have nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module. Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified. (i.e. If -g[123], every function gets `.eh_frame`. This behavior is strange but that is the status quo on GCC and Clang.) Let's take asan as an example. Other sanitizers are similar. `asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true, so every function gets `.eh_frame` if `-g[123]` is specified. This is the root cause that `-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame while `-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame. This patch * sets the nounwind attribute on sanitizer module ctor/dtor. * let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute. The "uwtable" mechanism is generic: synthesized functions not cloned/specialized from existing ones should consider `Function::createWithDefaultAttr` instead of `Function::create` if they want to get some default attributes which have more of module semantics. Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955 https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc. Differential Revision: https://reviews.llvm.org/D100251
2021-04-22 06:58:20 +08:00
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: !llvm.asan.globals = !{![[EXTRA_GLOBAL:[0-9]+]], ![[GLOBAL:[0-9]+]], ![[DYN_INIT_GLOBAL:[0-9]+]], ![[ATTR_GLOBAL:[0-9]+]], ![[DISABLE_INSTR_GLOBAL:[0-9]+]], ![[IGNORELISTED_GLOBAL:[0-9]+]], ![[SECTIONED_GLOBAL:[0-9]+]], ![[SPECIAL_GLOBAL:[0-9]+]], ![[STATIC_VAR:[0-9]+]], ![[LITERAL:[0-9]+]]}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[EXTRA_GLOBAL]] = !{{{.*}} ![[EXTRA_GLOBAL_LOC:[0-9]+]], !"extra_global", i1 false, i1 false}
// CHECK: ![[EXTRA_GLOBAL_LOC]] = !{!"{{.*}}extra-source.cpp", i32 1, i32 5}
// CHECK: ![[GLOBAL]] = !{{{.*}} ![[GLOBAL_LOC:[0-9]+]], !"global", i1 false, i1 false}
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// CHECK: ![[GLOBAL_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 10, i32 5}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[DYN_INIT_GLOBAL]] = !{{{.*}} ![[DYN_INIT_LOC:[0-9]+]], !"dyn_init_global", i1 true, i1 false}
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// CHECK: ![[DYN_INIT_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 11, i32 5}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: ![[ATTR_GLOBAL]] = !{{{.*attributed_global.*}}, null, null, i1 false, i1 true}
// CHECK: ![[DISABLE_INSTR_GLOBAL]] = !{{{.*disable_instrumentation_global.*}}, null, null, i1 false, i1 true}
// CHECK: ![[IGNORELISTED_GLOBAL]] = !{{{.*ignorelisted_global.*}}, null, null, i1 false, i1 true}
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// CHECK: ![[SECTIONED_GLOBAL]] = !{{{.*}} ![[SECTIONED_GLOBAL_LOC:[0-9]+]], !"sectioned_global", i1 false, i1 false}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: ![[SECTIONED_GLOBAL_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 16, i32 50}
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] [ v1 was reverted by c6ec352a6bde1995794c523adc2ebab802ccdf0a due to modpost failing; v2 fixes this. More info: https://github.com/ClangBuiltLinux/linux/issues/1045#issuecomment-640381783 ] This makes -fsanitize=kernel-address emit the correct globals constructors for the kernel. We had to do the following: * Disable generation of constructors that rely on linker features such as dead-global elimination. * Only instrument globals *not* in explicit sections. The kernel uses sections for special globals, which we should not touch. * Do not instrument globals that are prefixed with "__" nor that are aliased by a symbol that is prefixed with "__". For example, modpost relies on specially named aliases to find globals and checks their contents. Unfortunately modpost relies on size stored as ELF debug info and any padding of globals currently causes the debug info to cause size reported to be *with* redzone which throws modpost off. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203493 Tested: * With 'clang/test/CodeGen/asan-globals.cpp'. * With test_kasan.ko, we can see: BUG: KASAN: global-out-of-bounds in kasan_global_oob+0xb3/0xba [test_kasan] * allyesconfig, allmodconfig (x86_64) Reviewed By: glider Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D81390
2020-06-10 21:01:40 +08:00
// CHECK: ![[SPECIAL_GLOBAL]] = !{{{.*}} ![[SPECIAL_GLOBAL_LOC:[0-9]+]], !"__special_global", i1 false, i1 false}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: ![[SPECIAL_GLOBAL_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 18, i32 5}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[STATIC_VAR]] = !{{{.*}} ![[STATIC_LOC:[0-9]+]], !"static_var", i1 false, i1 false}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: ![[STATIC_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 22, i32 14}
IR: Make metadata typeless in assembly, clang side Match LLVM changes from r224257. llvm-svn: 224259
2014-12-16 03:10:08 +08:00
// CHECK: ![[LITERAL]] = !{{{.*}} ![[LITERAL_LOC:[0-9]+]], !"<string literal>", i1 false, i1 false}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// CHECK: ![[LITERAL_LOC]] = !{!"{{.*}}asan-globals.cpp", i32 23, i32 25}
[Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule Get rid of cached CodeGenModule::SanOpts, which was used to turn off sanitizer codegen options if current LLVM Module is blacklisted, and use plain LangOpts.Sanitize instead. 1) Some codegen decisions (turning TBAA or writable strings on/off) shouldn't depend on the contents of blacklist. 2) llvm.asan.globals should *always* be created, even if the module is blacklisted - soon Clang's CodeGen where we read sanitizer blacklist files, so we should properly report which globals are blacklisted to the backend. llvm-svn: 212499
2014-07-08 07:34:34 +08:00
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// IGNORELIST-SRC: !llvm.asan.globals = !{![[EXTRA_GLOBAL:[0-9]+]], ![[GLOBAL:[0-9]+]], ![[DYN_INIT_GLOBAL:[0-9]+]], ![[ATTR_GLOBAL:[0-9]+]], ![[DISABLE_INSTR_GLOBAL:[0-9]+]], ![[IGNORELISTED_GLOBAL:[0-9]+]], ![[SECTIONED_GLOBAL:[0-9]+]], ![[SPECIAL_GLOBAL:[0-9]+]], ![[STATIC_VAR:[0-9]+]], ![[LITERAL:[0-9]+]]}
[NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/ Replace filenames, variable names, check prefixes uses of blacklist with ignore list. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D113211
2021-11-17 20:40:55 +08:00
// IGNORELIST-SRC: ![[EXTRA_GLOBAL]] = !{{{.*}} ![[EXTRA_GLOBAL_LOC:[0-9]+]], !"extra_global", i1 false, i1 false}
// IGNORELIST-SRC: ![[EXTRA_GLOBAL_LOC]] = !{!"{{.*}}extra-source.cpp", i32 1, i32 5}
// IGNORELIST-SRC: ![[GLOBAL]] = !{{{.*}} null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[DYN_INIT_GLOBAL]] = !{{{.*}} null, null, i1 true, i1 true}
[asan] Add support for disable_sanitizer_instrumentation attribute For ASan this will effectively serve as a synonym for __attribute__((no_sanitize("address"))). Adding the disable_sanitizer_instrumentation to functions will drop the sanitize_XXX attributes on the IR level. This is the third reland of https://reviews.llvm.org/D114421. Now that TSan test is fixed (https://reviews.llvm.org/D120050) there should be no deadlocks. Differential Revision: https://reviews.llvm.org/D120055
2022-02-17 22:48:35 +08:00
// IGNORELIST-SRC: ![[ATTR_GLOBAL]] = !{{{.*attributed_global.*}}, null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[DISABLE_INSTR_GLOBAL]] = !{{{.*disable_instrumentation_global.*}}, null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[IGNORELISTED_GLOBAL]] = !{{{.*ignorelisted_global.*}}, null, null, i1 false, i1 true}
[NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/ Replace filenames, variable names, check prefixes uses of blacklist with ignore list. Reviewed By: jkorous Differential Revision: https://reviews.llvm.org/D113211
2021-11-17 20:40:55 +08:00
// IGNORELIST-SRC: ![[SECTIONED_GLOBAL]] = !{{{.*}} null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[SPECIAL_GLOBAL]] = !{{{.*}} null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[STATIC_VAR]] = !{{{.*}} null, null, i1 false, i1 true}
// IGNORELIST-SRC: ![[LITERAL]] = !{{{.*}} null, null, i1 false, i1 true}