summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-23/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* Make DataLayout Non-Optional in the ModuleMehdi Amini2015-03-041-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DataLayout keeps the string used for its creation. As a side effect it is no longer needed in the Module. This is "almost" NFC, the string is no longer canonicalized, you can't rely on two "equals" DataLayout having the same string returned by getStringRepresentation(). Get rid of DataLayoutPass: the DataLayout is in the Module The DataLayout is "per-module", let's enforce this by not duplicating it more than necessary. One more step toward non-optionality of the DataLayout in the module. Make DataLayout Non-Optional in the Module Module->getDataLayout() will never returns nullptr anymore. Reviewers: echristo Subscribers: resistor, llvm-commits, jholewinski Differential Revision: http://reviews.llvm.org/D7992 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231270
* [MSan][MIPS] VarArgHelper for MIPS64Mohit K. Bhakkad2015-02-181-0/+104
| | | | | | | | | | Reviewers: Reviewers: eugenis, kcc, samsonov, petarj Subscribers: dsanders, sagar, llvm-commits Differential Revision: http://reviews.llvm.org/D7182 llvm-svn: 229667
* [X86] Remove AVX512 pslldq/psrldq shift intrinsics. They aren't implemented ↵Craig Topper2015-02-181-6/+0
| | | | | | yet and when they are they should be done with shuffles like SSE2 and AVX2. llvm-svn: 229641
* [X86] Remove AVX2 and SSE2 pslldq and psrldq intrinsics. We can represent ↵Craig Topper2015-02-181-8/+0
| | | | | | them in IR with vector shuffles now. All their uses have been removed from clang in favor of shuffles. llvm-svn: 229640
* Transforms: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-2/+1
| | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) llvm-svn: 229202
* [msan] Fix "missing origin" in atomic store.Evgeniy Stepanov2015-02-061-1/+1
| | | | | | | | | | An atomic store always make the target location fully initialized (in the current implementation). It should not store origin. Initialized memory can't have meaningful origin, and, due to origin granularity (4 bytes) there is a chance that this extra store would overwrite meaningfull origin for an adjacent location. llvm-svn: 228444
* [msan] Update origin for the entire destination range on memory store.Evgeniy Stepanov2015-01-211-9/+49
| | | | | | | | | Previously we always stored 4 bytes of origin at the destination address even for 8-byte (and longer) stores. This should fix rare missing, or incorrect, origin stacks in MSan reports. llvm-svn: 226658
* [msan] Optimize -msan-check-constant-shadow.Evgeniy Stepanov2015-01-201-8/+26
| | | | | | | | The new code does not create new basic blocks in the case when shadow is a compile-time constant; it generates either an unconditional __msan_warning call or nothing instead. llvm-svn: 226569
* [MSan][LLVM][MIPS] Shadow and Origin offsets for MIPSMohit K. Bhakkad2015-01-201-25/+52
| | | | | | | | Reviewers: kcc, samsonov, petarj, eugenis Differential Revision: http://reviews.llvm.org/D6146 llvm-svn: 226565
* [Msan] Generalize instrumentation code to support FreeBSD mappingViktor Kutuzov2014-12-181-27/+106
| | | | | | Differential Revision: http://reviews.llvm.org/D6666 llvm-svn: 224514
* [msan] Avoid extra origin address realignment.Evgeniy Stepanov2014-12-051-21/+24
| | | | | | | | | Do not realign origin address if the corresponding application address is at least 4-byte-aligned. Saves 2.5% code size in track-origins mode. llvm-svn: 223464
* [msan] allow -fsanitize-coverage=N together with -fsanitize=memory, llvm partKostya Serebryany2014-12-031-1/+1
| | | | llvm-svn: 223312
* msan] Add compile-time checks for missing origins.Evgeniy Stepanov2014-12-031-10/+13
| | | | | | | | | | | | This change makes MemorySanitizer instrumentation a bit more strict about instructions that have no origin id assigned to them. This would have caught the bug that was fixed in r222918. This is re-commit of r222997, reverted in r223211, with 3 more missing origins added. llvm-svn: 223236
* Revert r222997. The newly added compile-time checks are finding missing ↵Nick Lewycky2014-12-031-10/+9
| | | | | | origins, testcase is being reduced and a PR will be posted shortly. llvm-svn: 223211
* [msan] Add compile-time checks for missing origins.Evgeniy Stepanov2014-12-011-9/+10
| | | | | | | | | | | This change makes MemorySanitizer instrumentation a bit more strict about instructions that have no origin id assigned to them. This would have caught the bug that was fixed in r222918. No functional change. llvm-svn: 222997
* [msan] Fix origin propagation for select of floats.Evgeniy Stepanov2014-11-281-3/+4
| | | | | | | | | | MSan does not assign origin for instrumentation temps (i.e. the ones that do not come from the application code), but "select" instrumentation erroneously tried to use one of those. https://code.google.com/p/memory-sanitizer/issues/detail?id=78 llvm-svn: 222918
* [msan] Remove indirect call wrapping code.Evgeniy Stepanov2014-11-271-89/+1
| | | | | | This functionality was only used in MSanDR, which is deprecated. llvm-svn: 222889
* Fix 80 cols caught by the linter...David Blaikie2014-11-141-2/+3
| | | | | | We have a linter running in our build now? llvm-svn: 221957
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-131-11/+11
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
* [msan] Make -msan-check-constant-shadow a bit stronger.Evgeniy Stepanov2014-10-241-3/+10
| | | | | | Allow (under the experimental flag) non-Instructions to participate in MSan checks. llvm-svn: 220601
* [msan] Emit checks for constant shadow values under an experimental flag.Evgeniy Stepanov2014-10-231-3/+12
| | | | | | Does not change the default behavior. llvm-svn: 220457
* [msan] Handle param-tls overflow.Evgeniy Stepanov2014-10-221-14/+34
| | | | | | | | ParamTLS (shadow for function arguments) is of limited size. This change makes all arguments that do not fit unpoisoned, and avoids writing past the end of a TLS buffer. llvm-svn: 220351
* IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignmentDavid Majnemer2014-10-201-4/+4
| | | | | | No functional change intended, just cleaning up some code. llvm-svn: 220187
* [msan] Fix handling of byval arguments with large alignment.Evgeniy Stepanov2014-10-171-1/+2
| | | | | | | MSan param-tls slots are 8-byte aligned. This change clips alignment of memcpy into param-tls to 8. llvm-svn: 220101
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Revert r215415 which causse MSan to crash on a great deal of C++ code.Chandler Carruth2014-08-131-10/+0
| | | | | | I've followed up on the original commit as well. llvm-svn: 215532
* msan: Handle musttail callsReid Kleckner2014-08-121-0/+10
| | | | | | | | | | | | | | | | First, avoid calling setTailCall(false) on musttail calls. The funciton prototypes should be "congruent", so the shadow layout should be exactly the same. Second, avoid inserting instrumentation after a musttail call to propagate the return value shadow. We don't need to propagate the result of a tail call, it should already be in the right place. Reviewed By: eugenis Differential Revision: http://reviews.llvm.org/D4331 llvm-svn: 215415
* [msan] Fix handling of array types.Evgeniy Stepanov2014-07-311-5/+16
| | | | | | | | Switch array type shadow from a single integer to an array of integers (i.e. make it per-element). This simplifies instrumentation of extractvalue and fixes PR20493. llvm-svn: 214398
* [msan] Avoid redundant origin stores.Evgeniy Stepanov2014-07-171-1/+4
| | | | | | | | | | | | | Origin is meaningless for fully initialized values. Avoid storing origin for function arguments that are known to be always initialized (i.e. shadow is a compile-time null constant). This is not about correctness, but purely an optimization. Seems to affect compilation time of blacklisted functions significantly. llvm-svn: 213239
* [msan] Fix handling of phi in blacklisted functions.Evgeniy Stepanov2014-07-071-2/+5
| | | | llvm-svn: 212454
* [msan] Stop propagating shadow in blacklisted functions.Evgeniy Stepanov2014-07-031-9/+11
| | | | | | | | | | | | | | With this change all values passed through blacklisted functions become fully initialized. Previous behavior was to initialize all loads in blacklisted functions, but apply normal shadow propagation logic for all other operation. This makes blacklist applicable in a wider range of situations. It also makes code for blacklisted functions a lot shorter, which works as yet another workaround for PR17409. llvm-svn: 212268
* Revert of r212265.Evgeniy Stepanov2014-07-031-11/+9
| | | | llvm-svn: 212266
* [msan] Stop propagating shadow in blacklisted functions.Evgeniy Stepanov2014-07-031-9/+11
| | | | | | | | | | | | | | With this change all values passed through blacklisted functions become fully initialized. Previous behavior was to initialize all loads in blacklisted functions, but apply normal shadow propagation logic for all other operation. This makes blacklist applicable in a wider range of situations. It also makes code for blacklisted functions a lot shorter, which works as yet another workaround for PR17409. llvm-svn: 212265
* msan: Stop stripping the 'tail' modifier off of callsReid Kleckner2014-06-301-6/+0
| | | | | | | This probably isn't necessary since msan started to unpoison the return value shadow memory before all calls. llvm-svn: 212061
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-261-1/+2
| | | | | | Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-261-2/+1
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
* [msan] Fix bad interaction between with-calls mode and chained origin tracking.Evgeniy Stepanov2014-06-251-1/+1
| | | | | | | | | | Origin history should only be recorded for uninitialized values, because it is meaningless otherwise. This change moves __msan_chain_origin to the runtime library side and makes it conditional on the corresponding shadow value. Previous code was correct, but _very_ inefficient. llvm-svn: 211700
* [msan] Handle X86 *.psad.* and *.pmadd.* intrinsics.Evgeniy Stepanov2014-06-181-0/+55
| | | | llvm-svn: 211156
* [msan] Fix a comment.Evgeniy Stepanov2014-06-171-2/+2
| | | | llvm-svn: 211094
* [msan] Fix handling of multiplication by a constant with a number of ↵Evgeniy Stepanov2014-06-171-1/+49
| | | | | | | | | | | | | | | | | | | trailing zeroes. Multiplication by an integer with a number of trailing zero bits leaves the same number of lower bits of the result initialized to zero. This change makes MSan take this into account in the case of multiplication by a compile-time constant. We don't handle the general, non-constant, case because (a) it's not going to be cheap (computation-wise); (b) multiplication by a partially uninitialized value in user code is a bad idea anyway. Constant case must be handled because it appears from LLVM optimization of a completely valid user code, as the test case in compiler-rt demonstrates. llvm-svn: 211092
* [msan] Workaround for invalid origins in shufflevector.Evgeniy Stepanov2014-06-091-4/+8
| | | | | | | | | Makes origin propagation ignore literal undef operands, and, in general, any operand we don't have origin for. https://code.google.com/p/memory-sanitizer/issues/detail?id=56 llvm-svn: 210472
* [msan] Fix vector pack intrinsic handling.Evgeniy Stepanov2014-06-091-8/+72
| | | | | | | | | This fixes a crash on MMX intrinsics, as well as a corner case in handling of all unsigned pack intrinsics. PR19953. llvm-svn: 210454
* Remove sanitizer blacklist from ASan/TSan/MSan function passes.Alexey Samsonov2014-06-021-19/+5
| | | | | | | | | | | | | | | | | Instrumentation passes now use attributes address_safety/thread_safety/memory_safety which are added by Clang frontend. Clang parses the blacklist file and adds the attributes accordingly. Currently blacklist is still used in ASan module pass to disable instrumentation for certain global variables. We should fix this as well by collecting the set of globals we're going to instrument in Clang and passing it to ASan in metadata (as we already do for dynamically-initialized globals and init-order checking). This change also removes -tsan-blacklist and -msan-blacklist LLVM commandline flags in favor of -fsanitize-blacklist= Clang flag. llvm-svn: 210038
* [msan] Remove an out-of-date comment.Evgeniy Stepanov2014-06-021-2/+0
| | | | | | MSan is no longer an "early prototype". llvm-svn: 210023
* [msan] Handle x86 vector pack intrinsics.Evgeniy Stepanov2014-06-021-0/+36
| | | | llvm-svn: 210020
* Use range-based for loops in ASan, TSan and MSanAlexey Samsonov2014-05-291-30/+28
| | | | llvm-svn: 209834
* [msan] Fix -fsanitize=memory -fno-integrated-as.Evgeniy Stepanov2014-05-071-1/+1
| | | | llvm-svn: 208211
* [C++] Use 'nullptr'.Craig Topper2014-04-281-1/+1
| | | | llvm-svn: 207394
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-28/+30
| | | | llvm-svn: 207196
OpenPOWER on IntegriCloud