summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* DataFlowSanitizer: fix a use-after-free. Spotted by libgmalloc.Peter Collingbourne2013-08-121-1/+4
| | | | llvm-svn: 188216
* Add SpecialCaseList::createOrDie() factory and use it in sanitizer passesAlexey Samsonov2013-08-121-3/+3
| | | | llvm-svn: 188169
* DataFlowSanitizer: Remove unreachable BBs so IR continues to verifyPeter Collingbourne2013-08-091-0/+3
| | | | | | | | under the args ABI. Differential Revision: http://llvm-reviews.chandlerc.com/D1316 llvm-svn: 188113
* Fix ARM build.Peter Collingbourne2013-08-081-1/+1
| | | | llvm-svn: 187944
* DataFlowSanitizer; LLVM changes.Peter Collingbourne2013-08-071-0/+1006
DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
OpenPOWER on IntegriCloud