Summary: The function computes full module name and coverts pc into offset.
Reviewers: kcc
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D26820
llvm-svn: 288711
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
This patch adds the __sanitizer_start_switch_fiber and
__sanitizer_finish_switch_fiber methods inspired from what can be found here
2ea64dd249 .
These methods are needed when the compiled software needs to implement
coroutines, fibers or the like. Without a way to annotate them, when the program
jumps to a stack that is not the thread stack, __asan_handle_no_return shows a
warning about that, and the fake stack mechanism may free fake frames that are
still in use.
Author: blastrock (Philippe Daouadi)
Reviewed in http://reviews.llvm.org/D20913
llvm-svn: 273260
Summary:
Sandboxed code may now pass additional arguments to
__sanitizer_sandbox_on_notify() to force all coverage data to be dumped to a
single file (the default is one file per module). The user may supply a file or
socket to write to. The latter option can be used to broker out the file writing
functionality. If -1 is passed, we pre-open a file.
llvm-svn: 209121
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
__sanitizer_set_report_path now accepts two special values - stderr and stdout
logging to other file descriptors is not supported anymore,
it's fragile in presence of multiple processes, fork, etc
llvm-svn: 192706
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
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
Mike Aizatsky