| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This probably isn't necessary since msan started to unpoison the return
value shadow memory before all calls.
llvm-svn: 212061
|
|
|
|
|
|
| |
Temporarily back out commits r211749, r211752 and r211754.
llvm-svn: 211814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Instead of asserting, output a message stating that a null pointer was found.
llvm-svn: 211430
|
|
|
|
| |
llvm-svn: 211156
|
|
|
|
| |
llvm-svn: 211094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Init-order and use-after-return modes can currently be enabled
by runtime flags. use-after-scope mode is not really working at the
moment.
The only problem I see is that users won't be able to disable extra
instrumentation for init-order and use-after-scope by a top-level Clang flag.
But this instrumentation was implicitly enabled for quite a while and
we didn't hear from users hurt by it.
llvm-svn: 210924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
|
|
|
|
|
|
|
| |
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
llvm-svn: 210803
|
|
|
|
|
|
|
| |
never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210497
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
This fixes a crash on MMX intrinsics, as well as a corner case in handling of
all unsigned pack intrinsics.
PR19953.
llvm-svn: 210454
|
|
|
|
|
|
|
| |
Now it should always point to the opening brace of the function (in
-asan-coverage=1 mode).
llvm-svn: 210266
|
|
|
|
|
|
| |
the commit from r206671, as requested by David Blaikie.
llvm-svn: 210239
|
|
|
|
|
|
| |
file emission.
llvm-svn: 210218
|
|
|
|
| |
llvm-svn: 210103
|
|
|
|
|
|
| |
aren't emitting line number zero, the .gcno format uses this to indicate that the next field is a filename.
llvm-svn: 210068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is no longer an "early prototype".
llvm-svn: 210023
|
|
|
|
| |
llvm-svn: 210020
|
|
|
|
|
|
| |
blacklisted functions
llvm-svn: 209946
|
|
|
|
|
|
| |
blacklisted functions
llvm-svn: 209939
|
|
|
|
| |
llvm-svn: 209834
|
|
|
|
|
|
|
|
|
| |
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209790
|
|
|
|
| |
llvm-svn: 209784
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime.
Don't assume that dynamically initialized globals are all initialized from
_GLOBAL__<module_name>I_ function. Instead, scan the llvm.global_ctors and
insert poison/unpoison calls to each function there.
Patch by Nico Weber!
llvm-svn: 209780
|
|
|
|
| |
llvm-svn: 209721
|
|
|
|
|
|
| |
each module.
llvm-svn: 209654
|
|
|
|
|
|
| |
see PR17409
llvm-svn: 209623
|
|
|
|
|
|
| |
(smaller than min(8,size)) by making two checks instead of one. This may slowdown some cases, e.g. long long on 32-bit or wide loads produced after loop unrolling. The benefit is higher sencitivity.
llvm-svn: 209508
|
|
|
|
| |
llvm-svn: 209040
|
|
|
|
| |
llvm-svn: 208769
|
|
|
|
|
|
|
|
|
| |
Most importantly, it gives debug location info to the coverage callback.
This change also removes 2 cases of unnecessary setDebugLoc when IRBuilder
is created with the same debug location.
llvm-svn: 208767
|
|
|
|
| |
llvm-svn: 208211
|
|
|
|
| |
llvm-svn: 208141
|
|
|
|
|
|
|
|
|
| |
callbacks
See https://code.google.com/p/address-sanitizer/issues/detail?id=305
Reviewed at http://reviews.llvm.org/D3607
llvm-svn: 207968
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
| |
llvm-svn: 207196
|
|
|
|
|
|
|
|
| |
to 0x40000000-0x60000000 to avoid address space clash with system libraries.
The solution has been proposed by tahabekireren@gmail.com in https://code.google.com/p/address-sanitizer/issues/detail?id=210
This is also known to fix some Chromium iOS tests.
llvm-svn: 207002
|
|
|
|
|
|
|
| |
Pass::doInitialization is supposed to return False when it did not
change the program, not when a fatal error occurs.
llvm-svn: 206975
|
|
|
|
|
|
| |
patch by Yuri Gribov
llvm-svn: 206883
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Transforms/...
edition.
This one is tricky for two reasons. We again have a couple of passes
that define something else before the includes as well. I've sunk their
name macros with the DEBUG_TYPE.
Also, InstCombine contains headers that need DEBUG_TYPE, so now those
headers #define and #undef DEBUG_TYPE around their code, leaving them
well formed modular headers. Fixing these headers was a large motivation
for all of these changes, as "leaky" macros of this form are hard on the
modules implementation.
llvm-svn: 206844
|
|
|
|
| |
llvm-svn: 206786
|
|
|
|
| |
llvm-svn: 206759
|
|
|
|
| |
llvm-svn: 206756
|
|
|
|
|
|
| |
memset/memcpy/memmove, replace the intrinsic with __asan_memset/etc. This makes the memset/etc handling more complete and consistent with what we do in msan. It may slowdown some cases (when the intrinsic was actually inlined) and speedup other cases (when it was not inlined)
llvm-svn: 206746
|
|
|
|
| |
llvm-svn: 206741
|
|
|
|
| |
llvm-svn: 206734
|