The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
This mirrors r225239 to all the rest sanitizers:
ASan, DFSan, LSan, MSan, TSan, UBSan.
Now the runtime flag type, name, default value and
description is located in the single place in the
.inc file.
llvm-svn: 225327
As mentioned in
https://code.google.com/p/address-sanitizer/issues/detail?id=365, when the
re-exec that adds the required DYLD_INSERT_LIBRARIES variable fails, ASan
currently continues to run, but things are broken (some memory can be
overwritten, interceptors don't work, ...). This patch aborts if the execv()
fails and prints an error message that DYLD_INSERT_LIBRARIES is required. It
also removes the "alllow_reexec" flag, since using it causes the same issues.
Reviewed at http://reviews.llvm.org/D6752
llvm-svn: 224712
When dump_instruction_bytes=1 and the instruction pointer doesn't point to the zero page, ASan prints 16 bytes starting at the instruction point.
llvm-svn: 218243
This change adds ASAN_OPTIONS=start_deactivated=1 flag. When present, ASan will
start in "deactivated" mode, with no heap poisoning, no quarantine, no stack
trace gathering, and minimal redzones. All this features come back when
__asan_init is called for the constructor of an instrumented library.
The primary use case for this feature is Android. Code itself is not
Android-specific, and this patch includes a Linux test for it.
llvm-svn: 199377
I still don't know what is causing our bootstrapped LTO buildbots to fail,
but llvm r194701 seems to be OK and I can't imagine that these changes could
cause the problem.
llvm-svn: 194790
Apple's bootstrapped LTO builds have been failing, and these changes (along
with llvm 194701) are the only things on the blamelist. I will either reapply
these changes or help debug the problem, depending on whether this fixes the
buildbots.
llvm-svn: 194779
This change adds ASan runtime option "strict-init-order" (off by default)
that makes init-order checker bark if global initializer accesses any global from different
translation unit (even if the latter is already initialized). strict init-order checking
doesn't play well with, e.g. LLVM registration machineries, and causes issue
https://code.google.com/p/address-sanitizer/issues/detail?id=178.
llvm-svn: 179843
library.
These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.
I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.
I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.
The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:
<prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
<prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
<prefix>/lib/clang/X.Y/include/sanitizer/...
But maybe others have different suggestions?
Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.
llvm-svn: 162822
Alexey Samsonov