This patch makes ASAN for aarch64 use the same shadow offset for all
currently supported VMAs (39 and 42 bits). The shadow offset is the
same for 39-bit (36).
llvm-svn: 252497
- Trim spaces.
- Use nullptr in place of 0 for pointer variables.
- Use '!p' in place of 'p == 0' for null pointer checks.
- Add blank lines to separate function definitions.
- Add 'extern "C"' or 'namespace foo' comments after the appropriate
closing brackets
This is a continuation of work from 409b7b82. The focus here is on the
various sanitizers (not sanitizer_common, as before).
Patch by Eugene Zelenko!
Differential Revision: http://reviews.llvm.org/D13225
llvm-svn: 248966
This patch adds a runtime check for asan, dfsan, msan, and tsan for
architectures that support multiple VMA size (like aarch64). Currently
the check only prints a warning indicating which is the VMA built and
expected against the one detected at runtime.
llvm-svn: 247413
Summary:
Teach all sanitizers to call abort() instead of _exit() after printing
an error report, if requested. This behavior is the default on Mac OS.
Reviewers: kcc, kubabrecka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12332
llvm-svn: 246205
Previously we had to call __sanitizer_cov_dump() from tool-specific
callbacks - instead, let sanitizer_common library handle this in a
single place.
This is a re-application of r245770, with slightly different approach
taken.
llvm-svn: 245890
This is required to properly re-apply r245770:
1) We should be able to dump coverage in __sanitizer::Die() if coverage
collection is turned on.
2) We don't want to explicitly do this in every single
sanitizer that supports it.
3) We don't want to link in coverage (and therefore symbolization) bits
into small sanitizers that don't support it (safestack).
The solution is to make InitializeCoverage() register its own Die()
callback that would call __sanitizer_cov_dump(). This callback should be
executed in addition to another tool-specific die callbacks (if there
are any).
llvm-svn: 245889
These changes break both autoconf Mac OS X buildbot (linker errors
due to wrong Makefiles) and CMake buildbot (safestack test failures).
llvm-svn: 245784
Previously we had to call __sanitizer_cov_dump() from tool-specific
callbacks - instead, let sanitizer_common library handle this in a single place.
llvm-svn: 245770
Summary:
Merge "exitcode" flag from ASan, LSan, TSan and "exit_code" from MSan
into one entity. Additionally, make sure sanitizer_common now uses the
value of common_flags()->exitcode when dying on error, so that this
flag will automatically work for other sanitizers (UBSan and DFSan) as
well.
User-visible changes:
* "exit_code" MSan runtime flag is now deprecated. If explicitly
specified, this flag will take precedence over "exitcode".
The users are encouraged to migrate to the new version.
* __asan_set_error_exit_code() and __msan_set_exit_code() functions
are removed. With few exceptions, we don't support changing runtime
flags during program execution - we can't make them thread-safe.
The users should use __sanitizer_set_death_callback()
that would call _exit() with proper exit code instead.
* Plugin tools (LSan and UBSan) now inherit the exit code of the parent
tool. In particular, this means that ASan would now crash the program
with exit code "1" instead of "23" if it detects leaks.
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12120
llvm-svn: 245734
The number of unaccessible pages at the beginning of the address
space can differ between processes on the same machine. Try different
values at runtime to protect as much memory as possible.
llvm-svn: 244364
We currently version `__asan_init` and when the ABI version doesn't match, the linker gives a `undefined reference to '__asan_init_v5'` message. From this, it might not be obvious that it's actually a version mismatch error. This patch makes the error message much clearer by changing the name of the undefined symbol to be `__asan_version_mismatch_check_xxx` (followed by the version string). We obviously don't want the initializer to be named like that, so it's a separate symbol that is used only for the purpose of version checking.
Reviewed at http://reviews.llvm.org/D11004
llvm-svn: 243004
Summary:
On Windows, thread injection by the kernel or other running processes is
a fairly common occurrence, so ASan should be resilient to it. The
comments on GetCurrentThread() say that it can return null, so we
shouldn't be CHECK failing if it does.
Sending control-C is one way to get the kernel to inject a thread into
your process, so I wrote a test around it.
Reviewers: llvm-commits
Subscribers: samsonov
Differential Revision: http://reviews.llvm.org/D11426
llvm-svn: 242948
include_if_exists=/path/to/sanitizer/options reads flags from the
file if it is present. "%b" in the include file path (for both
variants of the flag) is replaced with the basename of the main
executable.
llvm-svn: 242853
This is done by creating a named shared memory region, unlinking it
and setting up a private (i.e. copy-on-write) mapping of that instead
of a regular anonymous mapping. I've experimented with regular
(sparse) files, but they can not be scaled to the size of MSan shadow
mapping, at least on Linux/X86_64 and ext3 fs.
Controlled by a common flag, decorate_proc_maps, disabled by default.
This patch has a few shortcomings:
* not all mappings are annotated, especially in TSan.
* our handling of memset() of shadow via mmap() puts small anonymous
mappings inside larger named mappings, which looks ugly and can, in
theory, hit the mapping number limit.
llvm-svn: 238621
Summary:
During the review of http://reviews.llvm.org/D9199 where I had originally
changed the debug_mapping.cc test to accept hexadecimal values, we realized
that SHADOW_SCALE and SHADOW_GRANULARITY ought to be printed as decimal values.
This patch makes that change.
This patch also adds a '0x' prefix to the SHADOW_OFFSET to make it clear that
it is hexadecimal while the other two are decimal.
Reviewers: kcc, timurrrr, samsonov
Reviewed By: timurrrr, samsonov
Subscribers: samsonov, llvm-commits, sagar
Differential Revision: http://reviews.llvm.org/D9224
llvm-svn: 235798
On Windows, we have to know if a memory to be protected is mapped or not.
On POSIX, Mprotect was semantically different from mprotect most people know.
llvm-svn: 234602
Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
The experiments can be used to evaluate potential optimizations that remove
instrumentation (assess false negatives). Instead of completely removing
some instrumentation, you set Exp to a non-zero value (mask of optimization
experiments that want to remove instrumentation of this instruction).
If Exp is non-zero, this pass will emit special calls into runtime
(e.g. __asan_report_exp_load1 instead of __asan_report_load1). These calls
make runtime terminate the program in a special way (with a different
exit status). Then you run the new compiler on a buggy corpus, collect
the special terminations (ideally, you don't see them at all -- no false
negatives) and make the decision on the optimization.
The exact reaction to experiments in runtime is not implemented in this patch.
It will be defined and implemented in a subsequent patch.
http://reviews.llvm.org/D8198
llvm-svn: 232501
Summary:
LSan can be combined with a parent tool (for now it's only ASan).
Also, we allow LSAN_OPTIONS to override certain common flags. It means
we have to parse LSAN_OPTIONS early enough, before the rest of the
parent tool (including chunks of sanitizer_common) is initialized.
In future, we can use the same approach for UBSan, after we embed it
into ASan runtime in a similar way.
Test Plan: regression test suite
Reviewers: earthdok, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7577
llvm-svn: 229519
This is a re-commit of r224838 + r224839, previously reverted in r224850.
Test failures were likely (still can not reproduce) caused by two lit tests
using the same name for an intermediate build target.
llvm-svn: 224853
Now ASan deactivation doesn't modify common or ASan-specific runtime
flags. Flags stay constant after initialization, and "deactivation"
instead stashes initialized runtime state, and deactivates the
runtime. Activation then just restores the original state (possibly,
overriden by some activation flags provided in system property on
Android).
llvm-svn: 224614
Summary:
Reduce the dependency of allocator code on runtime flags. Instead,
pass a bunch of options that configure allocator behavior at
initialization or re-initialization. That would allow us to
cleaner modify allocator behavior during a program execution
when ASan is activated or de-activated.
Test Plan: regression test suite
Reviewers: kcc
Subscribers: llvm-commits, eugenis
Differential Revision: http://reviews.llvm.org/D6711
llvm-svn: 224605
SetCanPoisonMemory()/CanPoisonMemory() functions are now used
instead of "poison_heap" flag to determine if ASan is allowed
to poison the shadow memory. This allows to hot-patch this
value in runtime (e.g. during ASan activation) without introducing
a data race.
llvm-svn: 224395
Summary:
Introduce __asan::malloc_context_size atomic that is used to determine
required malloc/free stack trace size. It is initialized with
common_flags()->malloc_context_size flag, but can later be overwritten
at runtime (e.g. when ASan is activated / deactivated).
Test Plan: regression test suite
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6645
llvm-svn: 224305
Summary:
Turn "allocator_may_return_null" common flag into an
Allocator::may_return_null bool flag. We want to make sure
that common flags are immutable after initialization. There
are cases when we want to change this flag in the allocator
at runtime: e.g. in unit tests and during ASan activation
on Android.
Test Plan: regression test suite, real-life applications
Reviewers: kcc, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6623
llvm-svn: 224148
Alexander Potapenko