summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* hwasan: add -fsanitize=kernel-hwaddress flagAndrey Konovalov2018-04-131-6/+11
| | | | | | | | | This patch adds -fsanitize=kernel-hwaddress flag, that essentially enables -hwasan-kernel=1 -hwasan-recover=1 -hwasan-match-all-tag=0xff. Differential Revision: https://reviews.llvm.org/D45046 llvm-svn: 330044
* Fix a couple of layering violations in TransformsDavid Blaikie2018-03-211-1/+1
| | | | | | | | | | | | | Remove #include of Transforms/Scalar.h from Transform/Utils to fix layering. Transforms depends on Transforms/Utils, not the other way around. So remove the header and the "createStripGCRelocatesPass" function declaration (& definition) that is unused and motivated this dependency. Move Transforms/Utils/Local.h into Analysis because it's used by Analysis/MemoryBuiltins.cpp. llvm-svn: 328165
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+10
| | | | | | | | | | [llvm part, take 3] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327061
* Revert r327053.Kuba Mracek2018-03-081-7/+0
| | | | llvm-svn: 327055
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+7
| | | | | | | | | | [llvm part, take 2] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327053
* Revert r327029Kuba Mracek2018-03-081-6/+0
| | | | llvm-svn: 327033
* [asan] Fix a false positive ODR violation due to LTO ConstantMerge pass ↵Kuba Mracek2018-03-081-0/+6
| | | | | | | | | | [llvm part] This fixes a false positive ODR violation that is reported by ASan when using LTO. In cases, where two constant globals have the same value, LTO will merge them, which breaks ASan's ODR detection. Differential Revision: https://reviews.llvm.org/D43959 llvm-svn: 327029
* [ASan] Update uses of IRBuilder::CreateMemCpy to new API (NFC)Daniel Neilson2018-02-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the AddressSanitizer pass to cease using The old IRBuilder CreateMemCpy single-alignment API in favour of the new API that allows setting source and destination alignments independently. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324653
* [asan] Fix kernel callback naming in instrumentation module.Evgeniy Stepanov2018-01-251-3/+1
| | | | | | | | | | Right now clang uses "_n" suffix for some user space callbacks and "N" for the matching kernel ones. There's no need for this and it actually breaks kernel build with inline instrumentation. Use the same callback names for user space and the kernel (and also make them consistent with the names GCC uses). Patch by Andrey Konovalov. Differential Revision: https://reviews.llvm.org/D42423 llvm-svn: 323470
* asan: allow inline instrumentation for the kernelDmitry Vyukov2018-01-221-1/+0
| | | | | | | | | | | | Currently ASan instrumentation pass forces callback instrumentation when applied to the kernel. This patch changes the current behavior to allow using inline instrumentation in this case. Authored by andreyknvl. Reviewed in: https://reviews.llvm.org/D42384 llvm-svn: 323140
* Avoid int to string conversion in Twine or raw_ostream contexts.Benjamin Kramer2017-12-281-3/+4
| | | | | | Some output changes from uppercase hex to lowercase hex, no other functionality change intended. llvm-svn: 321526
* ASAN: Provide reliable debug info for local variables at -O0.Adrian Prantl2017-12-111-2/+12
| | | | | | | | | | | | | | | | | | | | | | The function stack poisioner conditionally stores local variables either in an alloca or in malloc'ated memory, which has the unfortunate side-effect, that the actual address of the variable is only materialized when the variable is accessed, which means that those variables are mostly invisible to the debugger even when compiling without optimizations. This patch stores the address of the local stack base into an alloca, which can be referred to by the debug info and is available throughout the function. This adds one extra pointer-sized alloca to each stack frame (but mem2reg can optimize it away again when optimizations are enabled, yielding roughly the same debug info quality as before in optimized code). rdar://problem/30433661 Differential Revision: https://reviews.llvm.org/D41034 llvm-svn: 320415
* Generalize llvm::replaceDbgDeclare and actually support the use-case thatAdrian Prantl2017-12-081-1/+2
| | | | | | is mentioned in the documentation (inserting a deref before the plus_uconst). llvm-svn: 320203
* [PowerPC][asan] Update asan to handle changed memory layouts in newer kernelsBill Seurer2017-12-071-1/+1
| | | | | | | | | | | | | | | In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the address sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64 and fixes up test cases. https://reviews.llvm.org/D40907 There is an associated patch for compiler-rt. Tested on several 4.x and 3.x kernel releases. llvm-svn: 320109
* [asan] Use dynamic shadow on 32-bit Android, try 2.Evgeniy Stepanov2017-11-201-11/+63
| | | | | | | | | | | | | | | | Summary: This change reverts r318575 and changes FindDynamicShadowStart() to keep the memory range it found mapped PROT_NONE to make sure it is not reused. We also skip MemoryRangeIsAvailable() check, because it is (a) unnecessary, and (b) would fail anyway. Reviewers: pcc, vitalybuka, kcc Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40203 llvm-svn: 318666
* Revert "[asan] Use dynamic shadow on 32-bit Android" and 3 more.Evgeniy Stepanov2017-11-181-63/+11
| | | | | | | | | | | | | | Revert the following commits: r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22. r318235 [asan] Prevent rematerialization of &__asan_shadow. r317948 [sanitizer] Remove unnecessary attribute hidden. r317943 [asan] Use dynamic shadow on 32-bit Android. MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer that may overlap with the address range that we plan to use for the dynamic shadow mapping. This is causing random startup crashes. llvm-svn: 318575
* [asan] Fix small X86_64 ShadowOffset for non-default shadow scaleWalter Lee2017-11-161-7/+9
| | | | | | | | | | The requirement is that shadow memory must be aligned to page boundaries (4k in this case). Use a closed form equation that always satisfies this requirement. Differential Revision: https://reviews.llvm.org/D39471 llvm-svn: 318421
* [asan] Fix size/alignment issues with non-default shadow scaleWalter Lee2017-11-161-2/+5
| | | | | | | | | | | | | | | Fix a couple places where the minimum alignment/size should be a function of the shadow granularity: - alignment of AllGlobals - the minimum left redzone size on the stack Added a test to verify that the metadata_array is properly aligned for shadow scale of 5, to be enabled when we add build support for testing shadow scale of 5. Differential Revision: https://reviews.llvm.org/D39470 llvm-svn: 318395
* [asan] Fallback to non-ifunc dynamic shadow on android<22.Evgeniy Stepanov2017-11-161-1/+3
| | | | | | | | | | | | Summary: Android < 22 does not support ifunc. Reviewers: pcc Subscribers: srhines, kubamracek, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40116 llvm-svn: 318369
* [asan] Prevent rematerialization of &__asan_shadow.Evgeniy Stepanov2017-11-151-12/+30
| | | | | | | | | | | | | | | | | | | | Summary: In the mode when ASan shadow base is computed as the address of an external global (__asan_shadow, currently on android/arm32 only), regalloc prefers to rematerialize this value to save register spills. Even in -Os. On arm32 it is rather expensive (2 loads + 1 constant pool entry). This changes adds an inline asm in the function prologue to suppress this behavior. It reduces AsanTest binary size by 7%. Reviewers: pcc, vitalybuka Subscribers: aemerson, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40048 llvm-svn: 318235
* Update some code.google.com linksHans Wennborg2017-11-131-4/+4
| | | | llvm-svn: 318115
* [asan] Use dynamic shadow on 32-bit Android.Evgeniy Stepanov2017-11-101-7/+39
| | | | | | | | | | | | | | | | | | | Summary: The following kernel change has moved ET_DYN base to 0x4000000 on arm32: https://marc.info/?l=linux-kernel&m=149825162606848&w=2 Switch to dynamic shadow base to avoid such conflicts in the future. Reserve shadow memory in an ifunc resolver, but don't use it in the instrumentation until PR35221 is fixed. This will eventually let use save one load per function. Reviewers: kcc Subscribers: aemerson, srhines, kubamracek, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D39393 llvm-svn: 317943
* [asan] Upgrade private linkage globals to internal linkage on COFFReid Kleckner2017-10-311-2/+7
| | | | | | | COFF comdats require symbol table entries, which means the comdat leader cannot have private linkage. llvm-svn: 317009
* [Transforms] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-10-191-41/+118
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 316190
* Define NetBSD/amd64 ASAN Shadow OffsetKamil Rytarowski2017-08-281-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: Catch up after compiler-rt changes and define kNetBSD_ShadowOffset64 as (1ULL << 46). Sponsored by <The NetBSD Foundation> Reviewers: kcc, joerg, filcab, vitalybuka, eugenis Reviewed By: eugenis Subscribers: llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D37234 llvm-svn: 311941
* Untabify.NAKAMURA Takumi2017-08-281-25/+25
| | | | llvm-svn: 311875
* [asan] Fix instruction emission ordering with dynamic shadow.Matt Morehouse2017-08-091-3/+8
| | | | | | | | | | | | | | | | Summary: Instrumentation to copy byval arguments is now correctly inserted after the dynamic shadow base is loaded. Reviewers: vitalybuka, eugenis Reviewed By: vitalybuka Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D36533 llvm-svn: 310503
* [asan] Fix asan dynamic shadow check before copyArgsPassedByValToAllocasVitaly Buka2017-08-071-1/+1
| | | | llvm-svn: 310242
* [asan] Disable checking of arguments passed by value for ↵Vitaly Buka2017-08-071-1/+2
| | | | | | | | --asan-force-dynamic-shadow Fails with "Instruction does not dominate all uses!" llvm-svn: 310241
* [asan] Copy arguments passed by value into explicit allocas for ASanVitaly Buka2017-07-181-0/+38
| | | | | | | | | | | | | | | | | | | | | Summary: 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. Submitted on behalf of @morehouse (Matt Morehouse) Reviewers: eugenis, vitalybuka Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D34789 llvm-svn: 308387
* 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
OpenPOWER on IntegriCloud