| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Also updated test files that were generated from this change.
llvm-svn: 194453
|
| |
|
|
| |
llvm-svn: 194374
|
| |
|
|
|
|
| |
LLVM optimizers may widen accesses to packed structures that overflow the structure itself, but should be in bounds up to the alignment of the object
llvm-svn: 193317
|
| |
|
|
| |
llvm-svn: 193268
|
| |
|
|
|
|
| |
Switch to sign-extension in r192575 caused 7% perf loss on 482.sphinx3.
llvm-svn: 192882
|
| |
|
|
|
|
|
| |
If a function has no_sanitize_thread attribute,
do not instrument memory accesses in it.
llvm-svn: 192871
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Given a global array G[N], which is declared in this CU and has static initializer
avoid instrumenting accesses like G[i], where 'i' is a constant and 0<=i<N.
Also add a bit of stats.
This eliminates ~1% of instrumentations on SPEC2006
and also partially helps when asan is being run together with coverage.
Reviewers: samsonov
Reviewed By: samsonov
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1947
llvm-svn: 192794
|
| |
|
|
|
|
|
|
| |
They were leftover from the old profiling support.
Patch by Alastair Murray.
llvm-svn: 192605
|
| |
|
|
|
|
|
|
| |
Currently MSan checks that arguments of *cvt* intrinsics are fully initialized.
That's too much to ask: some of them only operate on lower half, or even
quarter, of the input register.
llvm-svn: 192599
|
| |
|
|
| |
llvm-svn: 192575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
llvm-svn: 191835
|
| |
|
|
|
|
| |
Patch by Alp Toker.
llvm-svn: 191757
|
| |
|
|
| |
llvm-svn: 191676
|
| |
|
|
| |
llvm-svn: 191675
|
| |
|
|
| |
llvm-svn: 191576
|
| |
|
|
| |
llvm-svn: 191361
|
| |
|
|
| |
llvm-svn: 191287
|
| |
|
|
|
|
|
|
|
| |
Adds a flag to the MemorySanitizer pass that enables runtime rewriting of
indirect calls. This is part of MSanDR implementation and is needed to return
control to the DynamiRio-based helper tool on transition between instrumented
and non-instrumented modules. Disabled by default.
llvm-svn: 191006
|
| |
|
|
|
|
| |
enabled with the run-time option
llvm-svn: 190939
|
| |
|
|
| |
llvm-svn: 190905
|
| |
|
|
|
|
| |
10%-20% speedup for use-after-return
llvm-svn: 190863
|
| |
|
|
| |
llvm-svn: 190782
|
| |
|
|
|
|
| |
Compiler part.
llvm-svn: 190689
|
| |
|
|
|
|
|
| |
It works with clang, but GCC has different rules so we can't make all of those
hidden. This reverts commit r190534.
llvm-svn: 190536
|
| |
|
|
|
|
| |
Worth 100k on a linux/x86_64 Release+Asserts clang.
llvm-svn: 190534
|
| |
|
|
|
|
| |
at compile time instead of at run-time. llvm part
llvm-svn: 190407
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The work on this project was left in an unfinished and inconsistent state.
Hopefully someone will eventually get a chance to implement this feature, but
in the meantime, it is better to put things back the way the were. I have
left support in the bitcode reader to handle the case-range bitcode format,
so that we do not lose bitcode compatibility with the llvm 3.3 release.
This reverts the following commits: 155464, 156374, 156377, 156613, 156704,
156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575,
157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884,
157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100,
159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659,
159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736
llvm-svn: 190328
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
instead of having its own implementation.
The implementation of isTBAAVtableAccess is in TypeBasedAliasAnalysis.cpp
since it is related to the format of TBAA metadata.
The path for struct-path tbaa will be exercised by
test/Instrumentation/ThreadSanitizer/read_from_global.ll, vptr_read.ll, and
vptr_update.ll when struct-path tbaa is on by default.
llvm-svn: 190216
|
| |
|
|
| |
llvm-svn: 189796
|
| |
|
|
|
|
|
| |
Select condition shadow was being ignored resulting in false negatives.
This change OR-s sign-extended condition shadow into the result shadow.
llvm-svn: 189785
|
| |
|
|
| |
llvm-svn: 189473
|
| |
|
|
|
|
|
|
| |
custom functions.
Differential Revision: http://llvm-reviews.chandlerc.com/D1503
llvm-svn: 189408
|
| |
|
|
| |
llvm-svn: 189133
|
| |
|
|
|
|
|
|
| |
The code was erroneously reading overflow area shadow from the TLS slot,
bypassing the local copy. Reading shadow directly from TLS is wrong, because
it can be overwritten by a nested vararg call, if that happens before va_start.
llvm-svn: 189104
|
| |
|
|
| |
llvm-svn: 189091
|
| |
|
|
|
|
|
|
| |
functions, and vice versa, with wrappers.
Differential Revision: http://llvm-reviews.chandlerc.com/D1442
llvm-svn: 189054
|
| |
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1441
llvm-svn: 189053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the end.
There are situations which can affect the correctness (or at least expectation)
of the gcov output. For instance, if a call to __gcov_flush() occurs within a
block before the execution count is registered and then the program aborts in
some way, then that block will not be marked as executed. This is not normally
what the user expects.
If we move the code that's registering when a block is executed to the
beginning, we can catch these types of situations.
PR16893
llvm-svn: 188849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1395
llvm-svn: 188412
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 188293
|
| |
|
|
| |
llvm-svn: 188216
|
| |
|
|
| |
llvm-svn: 188169
|
| |
|
|
|
|
|
|
| |
under the args ABI.
Differential Revision: http://llvm-reviews.chandlerc.com/D1316
llvm-svn: 188113
|
| |
|
|
| |
llvm-svn: 188103
|
| |
|
|
| |
llvm-svn: 187944
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The globals being generated here were given the 'private' linkage type. However,
this caused them to end up in different sections with the wrong prefix. E.g.,
they would be in the __TEXT,__const section with an 'L' prefix instead of an 'l'
(lowercase ell) prefix.
The problem is that the linker will eat a literal label with 'L'. If a weak
symbol is then placed into the __TEXT,__const section near that literal, then it
cannot distinguish between the literal and the weak symbol.
Part of the problems here was introduced because the address sanitizer converted
some C strings into constant initializers with trailing nuls. (Thus putting them
in the __const section with the wrong prefix.) The others were variables that
the address sanitizer created but simply had the wrong linkage type.
llvm-svn: 187827
|