summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert r307342, r307343.Evgeniy Stepanov2017-07-071-37/+0
| | | | | | | | | | Revert "Copy arguments passed by value into explicit allocas for ASan." Revert "[asan] Add end-to-end tests for overflows of byval arguments." Build failure on lldb-x86_64-ubuntu-14.04-buildserver. Test failure on clang-cmake-aarch64-42vma and sanitizer-x86_64-linux-android. llvm-svn: 307345
* Copy arguments passed by value into explicit allocas for ASan.Evgeniy Stepanov2017-07-071-0/+37
| | | | | | | | | | | | | | ASan determines the stack layout from alloca instructions. Since arguments marked as "byval" do not have an explicit alloca instruction, ASan does not produce red zones for them. This commit produces an explicit alloca instruction and copies the byval argument into the allocated memory so that red zones are produced. Patch by Matt Morehouse. Differential revision: https://reviews.llvm.org/D34789 llvm-svn: 307342
* [Constants] If we already have a ConstantInt*, prefer to use ↵Craig Topper2017-07-061-1/+1
| | | | | | | | isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne. llvm-svn: 307292
* IR: Give function GlobalValue::getRealLinkageName() a less misleading name: ↵Peter Collingbourne2017-05-161-1/+1
| | | | | | | | | | | | dropLLVMManglingEscape(). This function gives the wrong answer on some non-ELF platforms in some cases. The function that does the right thing lives in Mangler.h. To try to discourage people from using this function, give it a different name. Differential Revision: https://reviews.llvm.org/D33162 llvm-svn: 303134
* [asan] Better workaround for gold PR19002.Evgeniy Stepanov2017-05-151-2/+11
| | | | | | See the comment for more details. Test in a follow-up CFE commit. llvm-svn: 303113
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-10/+9
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* Clean up DIExpression::prependDIExpr a little. (NFC)Adrian Prantl2017-04-281-1/+1
| | | | llvm-svn: 301662
* [asan] Fix dead stripping of globals on Linux.Evgeniy Stepanov2017-04-271-6/+104
| | | | | | | | | | | | | | | | | | | | | | Use a combination of !associated, comdat, @llvm.compiler.used and custom sections to allow dead stripping of globals and their asan metadata. Sometimes. Currently this works on LLD, which supports SHF_LINK_ORDER with sh_link pointing to the associated section. This also works on BFD, which seems to treat comdats as all-or-nothing with respect to linker GC. There is a weird quirk where the "first" global in each link is never GC-ed because of the section symbols. At this moment it does not work on Gold (as in the globals are never stripped). This is a second re-land of r298158. This time, this feature is limited to -fdata-sections builds. llvm-svn: 301587
* [asan] Put ctor/dtor in comdat.Evgeniy Stepanov2017-04-271-9/+48
| | | | | | | | | | | | | | | | | | | | When possible, put ASan ctor/dtor in comdat. The only reason not to is global registration, which can be TU-specific. This is not the case when there are no instrumented globals. This is also limited to ELF targets, because MachO does not have comdat, and COFF linkers may GC comdat constructors. The benefit of this is a lot less __asan_init() calls: one per DSO instead of one per TU. It's also necessary for the upcoming gc-sections-for-globals change on Linux, where multiple references to section start symbols trigger quadratic behaviour in gold linker. This is a second re-land of r298756. This time with a flag to disable the whole thing to avoid a bug in the gold linker: https://sourceware.org/bugzilla/show_bug.cgi?id=19002 llvm-svn: 301586
* [asan] Let the frontend disable gc-sections optimization for asan globals.Evgeniy Stepanov2017-04-241-16/+16
| | | | | | Also extend -asan-globals-live-support flag to all binary formats. llvm-svn: 301226
* PR32382: Fix emitting complex DWARF expressions.Adrian Prantl2017-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DWARF specification knows 3 kinds of non-empty simple location descriptions: 1. Register location descriptions - describe a variable in a register - consist of only a DW_OP_reg 2. Memory location descriptions - describe the address of a variable 3. Implicit location descriptions - describe the value of a variable - end with DW_OP_stack_value & friends The existing DwarfExpression code is pretty much ignorant of these restrictions. This used to not matter because we only emitted very short expressions that we happened to get right by accident. This patch makes DwarfExpression aware of the rules defined by the DWARF standard and now chooses the right kind of location description for each expression being emitted. This would have been an NFC commit (for the existing testsuite) if not for the way that clang describes captured block variables. Based on how the previous code in LLVM emitted locations, DW_OP_deref operations that should have come at the end of the expression are put at its beginning. Fixing this means changing the semantics of DIExpression, so this patch bumps the version number of DIExpression and implements a bitcode upgrade. There are two major changes in this patch: I had to fix the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca. When lowering a DBG_VALUE, the decision of whether to emit a register location description or a memory location description depends on the MachineLocation — register machine locations may get promoted to memory locations based on their DIExpression. (Future) optimization passes that want to salvage implicit debug location for variables may do so by appending a DW_OP_stack_value. For example: DBG_VALUE, [RBP-8] --> DW_OP_fbreg -8 DBG_VALUE, RAX --> DW_OP_reg0 +0 DBG_VALUE, RAX, DIExpression(DW_OP_deref) --> DW_OP_reg0 +0 All testcases that were modified were regenerated from clang. I also added source-based testcases for each of these to the debuginfo-tests repository over the last week to make sure that no synchronized bugs slip in. The debuginfo-tests compile from source and run the debugger. https://bugs.llvm.org/show_bug.cgi?id=32382 <rdar://problem/31205000> Differential Revision: https://reviews.llvm.org/D31439 llvm-svn: 300522
* [asan] Give global metadata private linkage.Evgeniy Stepanov2017-04-111-5/+6
| | | | | | | Internal linkage preserves names like "__asan_global_foo" which may account to 2% of unstripped binary size. llvm-svn: 299995
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-40/+51
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-23/+23
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-23/+23
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Revert "[asan] Put ctor/dtor in comdat."Evgeniy Stepanov2017-04-101-41/+9
| | | | | | This reverts commit r299696, which is causing mysterious test failures. llvm-svn: 299880
* Revert "[asan] Fix dead stripping of globals on Linux."Evgeniy Stepanov2017-04-101-103/+6
| | | | | | This reverts commit r299697, which caused a big increase in object file size. llvm-svn: 299879
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-49/+39
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-39/+49
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* [asan] Fix dead stripping of globals on Linux.Evgeniy Stepanov2017-04-061-6/+103
| | | | | | | | | | | | | | | | | | | | | | | Use a combination of !associated, comdat, @llvm.compiler.used and custom sections to allow dead stripping of globals and their asan metadata. Sometimes. Currently this works on LLD, which supports SHF_LINK_ORDER with sh_link pointing to the associated section. This also works on BFD, which seems to treat comdats as all-or-nothing with respect to linker GC. There is a weird quirk where the "first" global in each link is never GC-ed because of the section symbols. At this moment it does not work on Gold (as in the globals are never stripped). This is a re-land of r298158 rebased on D31358. This time, asan.module_ctor is put in a comdat as well to avoid quadratic behavior in Gold. llvm-svn: 299697
* [asan] Put ctor/dtor in comdat.Evgeniy Stepanov2017-04-061-9/+41
| | | | | | | | | | | | | | | | | | When possible, put ASan ctor/dtor in comdat. The only reason not to is global registration, which can be TU-specific. This is not the case when there are no instrumented globals. This is also limited to ELF targets, because MachO does not have comdat, and COFF linkers may GC comdat constructors. The benefit of this is a lot less __asan_init() calls: one per DSO instead of one per TU. It's also necessary for the upcoming gc-sections-for-globals change on Linux, where multiple references to section start symbols trigger quadratic behaviour in gold linker. This is a rebase of r298756. llvm-svn: 299696
* [asan] Delay creation of asan ctor.Evgeniy Stepanov2017-04-061-16/+13
| | | | | | | | | | | Create the constructor in the module pass. This in needed for the GC-friendly globals change, where the constructor can be put in a comdat in some cases, but we don't know about that in the function pass. This is a rebase of r298731 which was reverted due to a false alarm. llvm-svn: 299695
* Revert "[asan] Delay creation of asan ctor."Alex Shlyapnikov2017-03-271-13/+16
| | | | | | | | Speculative revert. Some libfuzzer tests are affected. This reverts commit r298731. llvm-svn: 298890
* Revert "[asan] Put ctor/dtor in comdat."Alex Shlyapnikov2017-03-271-41/+9
| | | | | | | | Speculative revert, some libfuzzer tests are affected. This reverts commit r298756. llvm-svn: 298889
* [asan] Put ctor/dtor in comdat.Evgeniy Stepanov2017-03-251-9/+41
| | | | | | | | | | | | | | | | When possible, put ASan ctor/dtor in comdat. The only reason not to is global registration, which can be TU-specific. This is not the case when there are no instrumented globals. This is also limited to ELF targets, because MachO does not have comdat, and COFF linkers may GC comdat constructors. The benefit of this is a lot less __asan_init() calls: one per DSO instead of one per TU. It's also necessary for the upcoming gc-sections-for-globals change on Linux, where multiple references to section start symbols trigger quadratic behaviour in gold linker. llvm-svn: 298756
* [asan] Delay creation of asan ctor.Evgeniy Stepanov2017-03-241-16/+13
| | | | | | | | | Create the constructor in the module pass. This in needed for the GC-friendly globals change, where the constructor can be put in a comdat in some cases, but we don't know about that in the function pass. llvm-svn: 298731
* Let llvm.objectsize be conservative with null pointersGeorge Burgess IV2017-03-211-2/+3
| | | | | | | | | | | This adds a parameter to @llvm.objectsize that makes it return conservative values if it's given null. This fixes PR23277. Differential Revision: https://reviews.llvm.org/D28494 llvm-svn: 298430
* Revert r298158.Evgeniy Stepanov2017-03-201-102/+6
| | | | | | | | Revert "[asan] Fix dead stripping of globals on Linux." OOM in gold linker. llvm-svn: 298288
* [asan] Fix dead stripping of globals on Linux.Evgeniy Stepanov2017-03-171-6/+102
| | | | | | | | | | | | | | | | | | | | | Use a combination of !associated, comdat, @llvm.compiler.used and custom sections to allow dead stripping of globals and their asan metadata. Sometimes. Currently this works on LLD, which supports SHF_LINK_ORDER with sh_link pointing to the associated section. This also works on BFD, which seems to treat comdats as all-or-nothing with respect to linker GC. There is a weird quirk where the "first" global in each link is never GC-ed because of the section symbols. At this moment it does not work on Gold (as in the globals are never stripped). Differential Revision: https://reviews.llvm.org/D30121 llvm-svn: 298158
* [AddressSanitizer] Put shadow at 0 for FuchsiaPetr Hosek2017-02-271-1/+6
| | | | | | | | | | The Fuchsia ASan runtime reserves the low part of the address space. Patch by Roland McGrath Differential Revision: https://reviews.llvm.org/D30426 llvm-svn: 296405
* [AddressSanitizer] Add PS4 offsetFilipe Cabecinhas2017-02-231-3/+7
| | | | llvm-svn: 295994
* AddressSanitizer: don't track swifterror memory addressesArnold Schwaighofer2017-02-151-3/+12
| | | | | | | | | | | | | | They are register promoted by ISel and so it makes no sense to treat them as memory. Inserting calls to the thread sanitizer would also generate invalid IR. You would hit: "swifterror value can only be loaded and stored from, or as a swifterror argument!" llvm-svn: 295230
* [WebAssembly] Add triple support for the new wasm object formatDan Gohman2017-01-171-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D26701 llvm-svn: 292252
* [asan] Don't overalign global metadata.Evgeniy Stepanov2017-01-121-11/+12
| | | | | | | | | Other than on COFF with incremental linking, global metadata should not need any extra alignment. Differential Revision: https://reviews.llvm.org/D28628 llvm-svn: 291859
* [asan] Refactor instrumentation of globals.Evgeniy Stepanov2017-01-121-145/+188
| | | | llvm-svn: 291858
* [asan] Set alignment of __asan_global_* globals to sizeof(GlobalStruct)Kuba Mracek2017-01-111-6/+3
| | | | | | | | When using profiling and ASan together (-fprofile-instr-generate -fcoverage-mapping -fsanitize=address), at least on Darwin, the section of globals that ASan emits (__asan_globals) is misaligned and starts at an odd offset. This really doesn't have anything to do with profiling, but it triggers the issue because profiling emits a string section, which can have arbitrary size. This patch changes the alignment to sizeof(GlobalStruct). Differential Revision: https://reviews.llvm.org/D28573 llvm-svn: 291715
* [asan] Change the visibility of ___asan_globals_registered to hiddenKuba Mracek2017-01-061-0/+1
| | | | | | | | This flag is used to track global registration in Mach-O and it doesn't need to be exported and visible. Differential Revision: https://reviews.llvm.org/D28250 llvm-svn: 291289
* [ASan] Make ASan instrument variable-masked loads and storesFilipe Cabecinhas2017-01-061-41/+55
| | | | | | | | | | | | Summary: Previously we only supported constant-masked loads and stores. Reviewers: kcc, RKSimon, pgousseau, gbedwell, vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28370 llvm-svn: 291238
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades and a change to the Bitcode record for DIGlobalVariable, that makes upgrading the old format unambiguous also for variables without DIExpressions. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 290153
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-1/+1
| | | | | | | | | | | | | | | | | This reverts commit 289920 (again). I forgot to implement a Bitcode upgrade for the case where a DIGlobalVariable has not DIExpression. Unfortunately it is not possible to safely upgrade these variables without adding a flag to the bitcode record indicating which version they are. My plan of record is to roll the planned follow-up patch that adds a unit: field to DIGlobalVariable into this patch before recomitting. This way we only need one Bitcode upgrade for both changes (with a version flag in the bitcode record to safely distinguish the record formats). Sorry for the churn! llvm-svn: 289982
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. This reapplies r289902 with additional testcase upgrades. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289920
* Revert "[IR] Remove the DIExpression field from DIGlobalVariable."Adrian Prantl2016-12-161-1/+1
| | | | | | This reverts commit 289902 while investigating bot berakage. llvm-svn: 289906
* [IR] Remove the DIExpression field from DIGlobalVariable.Adrian Prantl2016-12-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements PR31013 by introducing a DIGlobalVariableExpression that holds a pair of DIGlobalVariable and DIExpression. Currently, DIGlobalVariables holds a DIExpression. This is not the best way to model this: (1) The DIGlobalVariable should describe the source level variable, not how to get to its location. (2) It makes it unsafe/hard to update the expressions when we call replaceExpression on the DIGLobalVariable. (3) It makes it impossible to represent a global variable that is in more than one location (e.g., a variable with multiple DW_OP_LLVM_fragment-s). We also moved away from attaching the DIExpression to DILocalVariable for the same reasons. <rdar://problem/29250149> https://llvm.org/bugs/show_bug.cgi?id=31013 Differential Revision: https://reviews.llvm.org/D26769 llvm-svn: 289902
* [asan] Don't skip instrumentation of masked load/store unless we've seen a ↵Filipe Cabecinhas2016-12-141-3/+12
| | | | | | | | | | | | full load/store on that pointer. Reviewers: kcc, RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27625 llvm-svn: 289718
* [asan] Hook ClInstrumentWrites and ClInstrumentReads to masked operation ↵Filipe Cabecinhas2016-12-141-0/+4
| | | | | | | | | | | | instrumentation. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27548 llvm-svn: 289717
* [asan/win] Align global registration metadata to its sizeReid Kleckner2016-11-291-2/+13
| | | | | | | | This way, when the linker adds padding between globals, we can skip over the zero padding bytes and reliably find the start of the next metadata global. llvm-svn: 288096
* [asan] Make ASan compatible with linker dead stripping on WindowsReid Kleckner2016-11-211-47/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is similar to what was done for Darwin in rL264645 / http://reviews.llvm.org/D16737, but it uses COFF COMDATs to achive the same result instead of relying on new custom linker features. As on MachO, this creates one metadata global per instrumented global. The metadata global is placed in the custom .ASAN$GL section, which the ASan runtime will iterate over during initialization. There are no other references to the metadata, so normal linker dead stripping would discard it. However, the metadata is put in a COMDAT group with the instrumented global, so that it will be discarded if and only if the instrumented global is discarded. I didn't update the ASan ABI version check since this doesn't affect non-Windows platforms, and the WinASan ABI isn't really stable yet. Implementing this for ELF will require extending LLVM IR and MC a bit so that we can use non-COMDAT section groups. Reviewers: pcc, kcc, mehdi_amini, kubabrecka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26770 llvm-svn: 287576
* [asan] Turn on Mach-O global metadata liveness tracking by defaultAnna Zaks2016-11-171-1/+1
| | | | | | | | | | | | | | | | This patch turns on the metadata liveness tracking since all known issues have been resolved. The future has been implemented in https://reviews.llvm.org/D16737 and enables support of dead code stripping option on Mach-O platforms. As part of enabling the feature, I also plan on reverting the following patch to compiler-rt: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160704/369910.html Differential Revision: https://reviews.llvm.org/D26772 llvm-svn: 287235
* [AddressSanitizer] Add support for (constant-)masked loads and stores.Filipe Cabecinhas2016-11-151-14/+85
| | | | | | | | | | | | | | | | This patch adds support for instrumenting masked loads and stores under ASan, if they have a constant mask. isInterestingMemoryAccess now supports returning a mask to be applied to the loads, and instrumentMop will use it to generate additional checks. Added tests for v4i32 v8i32, and v4p0i32 (~v4i64) for both loads and stores (as well as a test to verify we don't add checks to non-constant masks). Differential Revision: https://reviews.llvm.org/D26230 llvm-svn: 287047
* [asan] Speed up compilation of large C++ stringmaps (tons of allocas) with ASanKuba Brecka2016-11-081-6/+12
| | | | | | | | This addresses PR30746, <https://llvm.org/bugs/show_bug.cgi?id=30746>. The ASan pass iterates over entry-block instructions and checks each alloca whether it's in NonInstrumentedStaticAllocaVec, which is apparently slow. This patch gathers the instructions to move during visitAllocaInst. Differential Revision: https://reviews.llvm.org/D26380 llvm-svn: 286296
OpenPOWER on IntegriCloud