| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential Revision: http://llvm-reviews.chandlerc.com/D1347
llvm-svn: 188229
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/D967
llvm-svn: 187924
|
|
|
|
| |
llvm-svn: 187726
|
|
|
|
| |
llvm-svn: 187653
|
|
|
|
| |
llvm-svn: 187417
|
|
|
|
| |
llvm-svn: 187414
|
|
|
|
|
|
|
| |
Let users override the normal behavior to run leak checking earlier in
the process. Also fix a couple nits here and there.
llvm-svn: 186581
|
|
|
|
| |
llvm-svn: 185913
|
|
|
|
| |
llvm-svn: 185066
|
|
|
|
| |
llvm-svn: 184542
|
|
|
|
|
|
| |
lit tests
llvm-svn: 183977
|
|
|
|
|
|
| |
Leak annotation similar to HeapChecker's IgnoreObject().
llvm-svn: 183412
|
|
|
|
|
|
|
| |
Objects allocated after a call to __lsan_disable() will be treated as
live memory. Also add a ScopedDisabler.
llvm-svn: 183099
|
|
|
|
| |
llvm-svn: 180102
|
|
|
|
| |
llvm-svn: 180012
|
|
|
|
| |
llvm-svn: 179592
|
|
|
|
|
|
|
| |
This time it's the full list scavenged from syscalls.h
Fixed return value type.
llvm-svn: 179378
|
|
|
|
|
|
| |
sanitizer lit_tests depend on fresh headers.
llvm-svn: 179293
|
|
|
|
|
|
|
| |
Pre- and post- hooks for linux syscalls. Not wired into anything, but exposed
through public interface.
llvm-svn: 179288
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: samsonov
Reviewed By: samsonov
CC: samsonov, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D652
llvm-svn: 179175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When prelink is installed in the system, prelink-ed
libraries map between 0x003000000000 and 0x004000000000 thus occupying the shadow Gap,
so we need so split the address space even further, like this:
|| [0x10007fff8000, 0x7fffffffffff] || HighMem ||
|| [0x02008fff7000, 0x10007fff7fff] || HighShadow ||
|| [0x004000000000, 0x02008fff6fff] || ShadowGap3 ||
|| [0x003000000000, 0x003fffffffff] || MidMem ||
|| [0x00087fff8000, 0x002fffffffff] || ShadowGap2 ||
|| [0x00067fff8000, 0x00087fff7fff] || MidShadow ||
|| [0x00008fff7000, 0x00067fff7fff] || ShadowGap ||
|| [0x00007fff8000, 0x00008fff6fff] || LowShadow ||
|| [0x000000000000, 0x00007fff7fff] || LowMem ||
Do it only if necessary.
Also added a bit of profiling code to make sure that the
mapping code is efficient.
Added a lit test to simulate prelink-ed libraries.
Unfortunately, this test does not work with binutils-gold linker.
If gold is the default linker the test silently passes.
Also replaced
__has_feature(address_sanitizer)
with
__has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
in two places.
Patch partially by Jakub Jelinek.
llvm-svn: 175263
|
|
|
|
|
|
| |
Currently, works only if symbolization happens in-process.
llvm-svn: 174501
|
|
|
|
|
|
| |
that makes sure users can include interface header
llvm-svn: 174058
|
|
|
|
|
|
| |
And make msan_interface.h C-compatible.
llvm-svn: 173928
|
|
|
|
|
|
| |
__has_feature is always defined at this point.
llvm-svn: 173920
|
|
|
|
|
|
|
|
| |
Moved everything users are not supposed to use to a private interface header.
Documented all public interfaces. Made them safe to use even if built without
MemorySanitizer.
llvm-svn: 173800
|
|
|
|
| |
llvm-svn: 173687
|
|
|
|
| |
llvm-svn: 172815
|
|
|
|
|
|
| |
running asan-ified binary under a debugger (e.g. gdb)
llvm-svn: 171217
|
|
|
|
| |
llvm-svn: 171199
|
|
|
|
| |
llvm-svn: 169860
|
|
|
|
|
|
|
|
| |
should be used by
the client programs to notify the tools that sandboxing is about to be turned on.
llvm-svn: 169732
|
|
|
|
|
|
| |
hooks on Linux: don't provide a default no-op implementations for hooks in runtime, and optionally call hooks if they are provided by the user. Don't force weak interface functions into runtime.
llvm-svn: 169641
|
|
|
|
|
|
| |
these functions are inserted by the instrumentation pass in use-after-scope mode
llvm-svn: 169201
|
|
|
|
| |
llvm-svn: 168306
|
|
|
|
|
|
| |
for error reports
llvm-svn: 167290
|
|
|
|
|
|
| |
__asan_on_error, so that ASan would call the latter even if it finds the error early (i.e. during module initialization)
llvm-svn: 165008
|
|
|
|
|
|
| |
Fall back to module+offset if user-provided symbolizer failed. Use weak function __asan_symbolize instead of __asan_set_symbolize_callback in ASan interface, so that we're able to symbolize reports for errors that happen before the main() is called, for example, during module initialization.
llvm-svn: 165000
|
|
|
|
|
|
| |
same time, remove ASan from CMake build on Windows after conversation with Timur. We don't want to support building ASan on Windows until it is in a working state.
llvm-svn: 164486
|
|
|
|
|
|
| |
file PATH.PID instead of stderr
llvm-svn: 163872
|
|
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
|