summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-7/+4
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* SpecialCaseList: Add support for parsing multiple input files.Alexey Samsonov2015-02-041-16/+21
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change allows users to create SpecialCaseList objects from multiple local files. This is needed to implement a proper support for -fsanitize-blacklist flag (allow users to specify multiple blacklists, in addition to default blacklist, see PR22431). DFSan can also benefit from this change, as DFSan instrumentation pass now accepts ABI-lists both from -fsanitize-blacklist= and -mllvm -dfsan-abilist flags. Go bindings are fixed accordingly. Test Plan: regression test suite Reviewers: pcc Subscribers: llvm-commits, axw, kcc Differential Revision: http://reviews.llvm.org/D7367 llvm-svn: 228155
* [PM] Replace the Pass argument to SplitEdge with specific analyses usedChandler Carruth2015-01-191-1/+1
| | | | | | | | | | | | | | | and updated. This may appear to remove handling for things like alias analysis when splitting critical edges here, but in fact no callers of SplitEdge relied on this. Similarly, all of them wanted to preserve LCSSA if there was any update of the loop info. That makes the interface much simpler. With this, all of BasicBlockUtils.h is free of Pass arguments and prepared for the new pass manager. This is tho majority of utilities that relied on pass arguments. llvm-svn: 226459
* [DFSAN][MIPS][LLVM] Defining ShadowPtrMask variable for MIPS64Peter Collingbourne2014-12-051-1/+12
| | | | | | | | | | | Patch by Kumar Sukhani! corresponding compiler-rt patch: http://reviews.llvm.org/D6437 clang patch: http://reviews.llvm.org/D6147 Differential Revision: http://reviews.llvm.org/D6459 llvm-svn: 223516
* [dfsan] Abort at runtime on indirect calls to uninstrumented vararg functions.Peter Collingbourne2014-11-051-10/+33
| | | | | | | | | | | | | We currently have no infrastructure to support these correctly. This is accomplished by generating a call to a runtime library function that aborts at runtime in place of the regular wrapper for such functions. Direct calls are rewritten in the usual way during traversal of the caller's IR. We also remove the "split-stack" attribute from such wrappers, as the code generator cannot currently handle split-stack vararg functions. llvm-svn: 221360
* [dfsan] New calling convention for custom functions with variadic arguments.Peter Collingbourne2014-10-301-9/+22
| | | | | | | | | | | | | | | | | | | Summary: The previous calling convention prevented custom functions from being able to access argument labels unless it knew how many variadic arguments there were, and of which type. This restriction made it impossible to correctly model functions in the printf family, as it is legal to pass more arguments than required to those functions. We now pass arguments in the following order: non-vararg arguments labels for non-vararg arguments [if vararg function, pointer to array of labels for vararg arguments] [if non-void function, pointer to label for return value] vararg arguments Differential Revision: http://reviews.llvm.org/D6028 llvm-svn: 220906
* DebugInfo+DFSan: Ensure that debug info references to llvm::Functions remain ↵David Blaikie2014-10-071-0/+10
| | | | | | | | | | | | | | | | | | | | | | pointing to the underlying function when wrappers are created This is somewhat the inverse of how similar bugs in DAE and ArgPromo manifested and were addressed. In those passes, individual call sites were visited explicitly, and then the old function was deleted. This left the debug info with a null llvm::Function* that needed to be updated to point to the new function. In the case of DFSan, it RAUWs the old function with the wrapper, which includes debug info. So now the debug info refers to the wrapper, which doesn't actually have any instructions with debug info in it, so it is ignored entirely - resulting in a DW_TAG_subprogram with no high/low pc, etc. Instead, fix up the debug info to refer to the original function after the RAUW messed it up. Reviewed/discussed with Peter Collingbourne on the llvm-dev mailing list. llvm-svn: 219249
* Introduce support for custom wrappers for vararg functions.Lorenzo Martignoni2014-09-301-9/+18
| | | | | | Differential Revision: http://reviews.llvm.org/D5412 llvm-svn: 218671
* [asan] Assign a low branch weight to ASan's slow path, patch by Jonas ↵Kostya Serebryany2014-09-021-1/+1
| | | | | | Wagner. This speeds up asan (at least on SPEC) by 1%-5% or more. Also fix lint in dfsan. llvm-svn: 216972
* unique_ptrify the result of SpecialCaseList::createDavid Blaikie2014-09-021-1/+1
| | | | llvm-svn: 216925
* Fix some cases where StringRef was being passed by const reference. Remove ↵Craig Topper2014-08-301-3/+3
| | | | | | const from some other StringRefs since its implicitly const already. llvm-svn: 216820
* 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
* [dfsan] Fix non-determinism bug in non-zero label check annotator.Peter Collingbourne2014-08-221-10/+8
| | | | | | | We now use a std::vector instead of a DenseSet to store the list of label checks so that we can iterate over it deterministically. llvm-svn: 216255
* [dfsan] Treat vararg custom functions like unimplemented functions.Peter Collingbourne2014-08-201-1/+1
| | | | | | | | | Because declarations of these functions can appear in places like autoconf checks, they have to be handled somehow, even though we do not support vararg custom functions. We do so by printing a warning and calling the uninstrumented function, as we do for unimplemented functions. llvm-svn: 216042
* [dfsan] Try not to create too many additional basic blocks in functions whichPeter Collingbourne2014-08-061-20/+46
| | | | | | | already have a large number of blocks. Works around a performance issue with the greedy register allocator. llvm-svn: 214944
* [dfsan] Correctly handle loads and stores of zero size.Peter Collingbourne2014-08-011-0/+8
| | | | llvm-svn: 214561
* [dfsan] Introduce further optimization to reduce the number of union queries.Peter Collingbourne2014-07-151-0/+36
| | | | | | | Specifically, do not compute a union if it is statically known that one shadow set subsumes the other. llvm-svn: 213100
* [dfsan] Introduce an optimization to reduce the number of union queries.Peter Collingbourne2014-07-151-1/+34
| | | | | | | Specifically, when building a union query, if we are dominated by an identical query then use the result of that query instead. llvm-svn: 213047
* [dfsan] Move combineShadows to DFSanFunction in preparation for it to use a ↵Peter Collingbourne2014-07-151-18/+16
| | | | | | domtree. llvm-svn: 213046
* [dfsan] Handle bitcast aliases.Peter Collingbourne2014-07-101-2/+2
| | | | llvm-svn: 212668
* Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.Alexey Samsonov2014-07-091-8/+53
| | | | | | | | | | | | | | | | Turn llvm::SpecialCaseList into a simple class that parses text files in a specified format and knows nothing about LLVM IR. Move this class into LLVMSupport library. Implement two users of this class: * DFSanABIList in DFSan instrumentation pass. * SanitizerBlacklist in Clang CodeGen library. The latter will be modified to use actual source-level information from frontend (source file names) instead of unstable LLVM IR things (LLVM Module identifier). Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils. No functionality change. llvm-svn: 212643
* Delete getAliasedGlobal.Rafael Espindola2014-05-161-1/+1
| | | | llvm-svn: 209040
* [C++] Use 'nullptr'. Transforms edition.Craig Topper2014-04-251-10/+13
| | | | llvm-svn: 207196
* Fix handling of missing DataLayout in sanitizers.Evgeniy Stepanov2014-04-231-1/+1
| | | | | | | Pass::doInitialization is supposed to return False when it did not change the program, not when a fatal error occurs. llvm-svn: 206975
* Implement depth_first and inverse_depth_first range factory functions.David Blaikie2014-04-111-3/+2
| | | | | | | | | | | | | | Also updated as many loops as I could find using df_begin/idf_begin - strangely I found no uses of idf_begin. Is that just used out of tree? Also a few places couldn't use df_begin because either they used the member functions of the depth first iterators or had specific ordering constraints (I added a comment in the latter case). Based on a patch by Jim Grosbach. (Jim - you just had iterator_range<T> where you needed iterator_range<idf_iterator<T>>) llvm-svn: 206016
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
* Revert "Prevent alias from pointing to weak aliases."Rafael Espindola2014-03-261-1/+2
| | | | | | | | | This reverts commit r204781. I will follow up to with msan folks to see what is what they were trying to do with aliases to weak aliases. llvm-svn: 204784
* Prevent alias from pointing to weak aliases.Rafael Espindola2014-03-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204781
* Remove some dead assignements found by scan-buildArnaud A. de Grandmaison2014-03-211-1/+0
| | | | llvm-svn: 204526
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Layering] Move InstVisitor.h into the IR library as it is prettyChandler Carruth2014-03-061-1/+1
| | | | | | obviously coupled to the IR. llvm-svn: 203064
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-051-2/+2
| | | | | | class. llvm-svn: 202953
* Make DataLayout a plain object, not a pass.Rafael Espindola2014-02-251-2/+3
| | | | | | | Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. llvm-svn: 202168
* Make some DataLayout pointers const.Rafael Espindola2014-02-241-1/+1
| | | | | | No functionality change. Just reduces the noise of an upcoming patch. llvm-svn: 202087
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* [dfsan] Simplify code after r197677.Evgeniy Stepanov2013-12-191-19/+14
| | | | llvm-svn: 197679
* Add an explicit insert point argument to SplitBlockAndInsertIfThen.Evgeniy Stepanov2013-12-191-6/+4
| | | | | | | | Currently SplitBlockAndInsertIfThen requires that branch condition is an Instruction itself, which is very inconvenient, because it is sometimes an Operator, or even a Constant. llvm-svn: 197677
* Introduce two command-line flags for the instrumentation pass to control ↵Peter Collingbourne2013-11-211-10/+33
| | | | | | | | | | | | | | whether the labels of pointers should be ignored in load and store instructions The new command line flags are -dfsan-ignore-pointer-label-on-store and -dfsan-ignore-pointer-label-on-load. Their default value matches the current labelling scheme. Additionally, the function __dfsan_union_load is marked as readonly. Patch by Lorenzo Martignoni! Differential Revision: http://llvm-reviews.chandlerc.com/D2187 llvm-svn: 195382
* 80 colsAlexey Samsonov2013-08-281-3/+4
| | | | llvm-svn: 189473
* DataFlowSanitizer: Implement trampolines for function pointers passed to ↵Peter Collingbourne2013-08-271-3/+77
| | | | | | | | custom functions. Differential Revision: http://llvm-reviews.chandlerc.com/D1503 llvm-svn: 189408
* DataFlowSanitizer: correctly combine labels in the case where they are equal.Peter Collingbourne2013-08-231-1/+1
| | | | llvm-svn: 189133
* 80 colsAlexey Samsonov2013-08-231-3/+3
| | | | llvm-svn: 189091
* DataFlowSanitizer: Replace non-instrumented aliases of instrumented ↵Peter Collingbourne2013-08-221-1/+12
| | | | | | | | functions, and vice versa, with wrappers. Differential Revision: http://llvm-reviews.chandlerc.com/D1442 llvm-svn: 189054
* DataFlowSanitizer: Factor the wrapper builder out to buildWrapperFunction.Peter Collingbourne2013-08-221-20/+33
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D1441 llvm-svn: 189053
* DataFlowSanitizer: Prefix the name of each instrumented function with "dfs$".Peter Collingbourne2013-08-221-7/+51
| | | | | | | | | | | | | | | | DFSan changes the ABI of each function in the module. This makes it possible for a function with the native ABI to be called with the instrumented ABI, or vice versa, thus possibly invoking undefined behavior. A simple way of statically detecting instances of this problem is to prepend the prefix "dfs$" to the name of each instrumented-ABI function. This will not catch every such problem; in particular function pointers passed across the instrumented-native barrier cannot be used on the other side. These problems could potentially be caught dynamically. Differential Revision: http://llvm-reviews.chandlerc.com/D1373 llvm-svn: 189052
* DataFlowSanitizer: Add a debugging feature to help us track nonzero labels.Peter Collingbourne2013-08-151-2/+48
| | | | | | | | | | | | | | | | | | Summary: When the -dfsan-debug-nonzero-labels parameter is supplied, the code is instrumented such that when a call parameter, return value or load produces a nonzero label, the function __dfsan_nonzero_label is called. The idea is that a debugger breakpoint can be set on this function in a nominally label-free program to help identify any bugs in the instrumentation pass causing labels to be introduced. Reviewers: eugenis CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1405 llvm-svn: 188472
* DataFlowSanitizer: Instrumentation for memset.Peter Collingbourne2013-08-141-1/+22
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D1395 llvm-svn: 188412
* DataFlowSanitizer: greylist is now ABI list.Peter Collingbourne2013-08-141-96/+271
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces the old incomplete greylist functionality with an ABI list, which can provide more detailed information about the ABI and semantics of specific functions. The pass treats every function in the "uninstrumented" category in the ABI list file as conforming to the "native" (i.e. unsanitized) ABI. Unless the ABI list contains additional categories for those functions, a call to one of those functions will produce a warning message, as the labelling behaviour of the function is unknown. The other supported categories are "functional", "discard" and "custom". - "discard" -- This function does not write to (user-accessible) memory, and its return value is unlabelled. - "functional" -- This function does not write to (user-accessible) memory, and the label of its return value is the union of the label of its arguments. - "custom" -- Instead of calling the function, a custom wrapper __dfsw_F is called, where F is the name of the function. This function may wrap the original function or provide its own implementation. Differential Revision: http://llvm-reviews.chandlerc.com/D1345 llvm-svn: 188402
* dfsan: fix lint warningsDmitry Vyukov2013-08-131-2/+2
| | | | llvm-svn: 188293
OpenPOWER on IntegriCloud