Summary:
__builtion___clear_cache maps to clear_cache function. On Linux,
clear_cache functions makes a syscall and does an abort if syscall fails.
Replace the abort by an assert so that non-debug builds do not abort
if the syscall fails.
Fixes PR34588.
Reviewers: rengolin, compnerd, srhines, peter.smith, joerg
Reviewed By: rengolin
Subscribers: aemerson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D37788
llvm-svn: 314322
Summary:
The current implementation of the allocator returning freed memory
back to OS (controlled by allocator_release_to_os_interval_ms flag)
requires sorting of the free chunks list, which has two major issues,
first, when free list grows to millions of chunks, sorting, even the
fastest one, is just too slow, and second, sorting chunks in place
is unacceptable for Scudo allocator as it makes allocations more
predictable and less secure.
The proposed approach is linear in complexity (altough requires quite
a bit more temporary memory). The idea is to count the number of free
chunks on each memory page and release pages containing free chunks
only. It requires one iteration over the free list of chunks and one
iteration over the array of page counters. The obvious disadvantage
is the allocation of the array of the counters, but even in the worst
case we support (4T allocator space, 64 buckets, 16 bytes bucket size,
full free list, which leads to 2 bytes per page counter and ~17M page
counters), requires just about 34Mb of the intermediate buffer (comparing
to ~64Gb of actually allocated chunks) and usually it stays under 100K
and released after each use. It is expected to be a relatively rare event,
releasing memory back to OS, keeping the buffer between those runs
and added complexity of the bookkeeping seems unnesessary here (it can
always be improved later, though, never say never).
The most interesting problem here is how to calculate the number of chunks
falling into each memory page in the bucket. Skipping all the details,
there are three cases when the number of chunks per page is constant:
1) P >= C, P % C == 0 --> N = P / C
2) C > P , C % P == 0 --> N = 1
3) C <= P, P % C != 0 && C % (P % C) == 0 --> N = P / C + 1
where P is page size, C is chunk size and N is the number of chunks per
page and the rest of the cases, where the number of chunks per page is
calculated on the go, during the page counter array iteration.
Among the rest, there are still cases where N can be deduced from the
page index, but they require not that much less calculations per page
than the current "brute force" way and 2/3 of the buckets fall into
the first three categories anyway, so, for the sake of simplicity,
it was decided to stick to those two variations. It can always be
refined and improved later, should we see that brute force way slows
us down unacceptably.
Reviewers: eugenis, cryptoad, dvyukov
Subscribers: kubamracek, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D38245
llvm-svn: 314311
Summary:
MSR instruction in Thumb2 does not support immediate operand.
Fix this by moving the condition for V7-M to Thumb2 since V7-M support
Thumb2 only. With this change, aeabi_cfcmp.s and aeabi_cdcmp.S files can
be assembled in Thumb2 mode. (This is split out from the review D38227).
Reviewers: compnerd, peter.smith, srhines, weimingz, rengolin, kristof.beyls
Reviewed By: compnerd
Subscribers: aemerson, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D38268
llvm-svn: 314284
Summary:
Align __aeabi_memclr to 4 bytes. All other ARM functions are already aligned to
4-bytes in compiler-rt.
(Split off from review D38227)
Reviewers: compnerd, peter.smith, srhines, weimingz, rengolin, kristof.beyls
Reviewed By: compnerd
Subscribers: aemerson, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D38271
llvm-svn: 314255
Summary:
Previous parts: D38139, D38183.
In this part of the refactor, we abstract the Linux vs Android TSD dissociation
in favor of a Exclusive vs Shared one, allowing for easier platform introduction
and configuration.
Most of this change consist of shuffling the files around to reflect the new
organization.
We introduce `scudo_platform.h` where platform specific definition lie. This
involves the TSD model and the platform specific allocator parameters. In an
upcoming CL, those will be configurable via defines, but we currently stick
with conservative defaults.
Reviewers: alekseyshl, dvyukov
Reviewed By: alekseyshl, dvyukov
Subscribers: srhines, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38244
llvm-svn: 314224
Summary:
The module list should only be invalidated by dlopen and dlclose,
so the symbolizer should only re-generate it when we've hit one of those functions.
Reviewers: kubamracek, rnk, vitalybuka
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37268
llvm-svn: 314219
Summary:
Platforms that don't implement procmaps (primarily fuchsia and windows) still expose
the procmaps API when including sanitizer_procmaps.h, despite not implementing the functions
provided by that header. Ensure that the API is only exposed on platforms that implement it.
Reviewers: vitalybuka, alekseyshl, kubamracek
Subscribers: llvm-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D38187
llvm-svn: 314149
Summary:
Following D38139, we now consolidate the TSD definition, merging the shared
TSD definition with the exclusive TSD definition. We introduce a boolean set
at initializaton denoting the need for the TSD to be unlocked or not. This
adds some unused members to the exclusive TSD, but increases consistency and
reduces the definitions fragmentation.
We remove the fallback mechanism from `scudo_allocator.cpp` and add a fallback
TSD in the non-shared version. Since the shared version doesn't require one,
this makes overall more sense.
There are a couple of additional cosmetic changes: removing the header guards
from the remaining `.inc` files, added error string to a `CHECK`.
Question to reviewers: I thought about friending `getTSDAndLock` in `ScudoTSD`
so that the `FallbackTSD` could `Mutex.Lock()` directly instead of `lock()`
which involved zeroing out the `Precedence`, which is unused otherwise. Is it
worth doing?
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: dvyukov
Subscribers: srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D38183
llvm-svn: 314110
Summary:
Part of https://github.com/google/sanitizers/issues/637
Standalone ubsan needs signal and sigaction handlers and interceptors.
Plugin mode should rely on parent tool.
Reviewers: eugenis, alekseyshl
Subscribers: kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37895
llvm-svn: 314052
Summary:
We are going through an overhaul of Scudo's TSD, to allow for new platforms
to be integrated more easily, and make the code more sound.
This first part is mostly renaming, preferring some shorter names, correcting
some comments. I removed `getPrng` and `getAllocatorCache` to directly access
the members, there was not really any benefit to them (and it was suggested by
Dmitry in D37590).
The only functional change is in `scudo_tls_android.cpp`: we enforce bounds to
the `NumberOfTSDs` and most of the logic in `getTSDAndLockSlow` is skipped if we
only have 1 TSD.
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: dvyukov
Subscribers: llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D38139
llvm-svn: 313987
Don't overwrite exit code in LSan when running on top of ASan in recovery mode
to avoid breakage of users code due to found leaks.
Patch by Slava Barinov.
Differential Revision: https://reviews.llvm.org/D38026
llvm-svn: 313966
This commit annotates the block parameters of the following functions
declared in compiler-rt with 'noescape':
- dispatch_sync
- dispatch_barrier_sync
- dispatch_once
- dispatch_apply
This is needed to commit the patch that adds support for 'noescape' in
clang (see https://reviews.llvm.org/D32210) since these functions are
annotated with 'noescape' in the SDK header files.
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313929
Summary:
Remove dependency on std::unique_ptr<...> for the global representing
the installed XRay implementation.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38121
llvm-svn: 313871
Summary:
On Linux we may need preinit_array in static lib and
ubsan_standalone_initializer in shared lib.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38013
llvm-svn: 313851
This causes a linker error because of duplicate symbol since
ReportDeadlySignal is defined both in sanitizer_common_libcdep and
sanitizer_fuchsia.
Differential Revision: https://reviews.llvm.org/D37952
llvm-svn: 313641
This eliminates a few inconsistencies between the symbol sets exported
by RTUBSan and RTUBSan_minimal:
* Handlers for nonnull_return were missing from the minimal RT, and
are now added in.
* The minimal runtime exported recoverable handlers for
builtin_unreachable and missing_return. These are not supposed to
exist, and are now removed.
llvm-svn: 313614
Summary:
1. Update ubsan_interface.inc to make the test happy.
2. Switch interface_symbols_linux and interface_symbols_darwin to C++ to import __ubsan_handle_dynamic_type_cache_miss
3. Switch interface_symbols_windows to C++ for consistency.
Reviewers: rnk, zturner
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D37986
llvm-svn: 313551
This should fix an issue which arises when running check-compiler-rt on
the coverage bot:
http://green.lab.llvm.org/green/job/clang-stage2-coverage-R_build/1590/
The bot doesn't build the sanitizers, but the check-compiler-rt target
always expects the profile runtime to exist.
llvm-svn: 313549
This is used only to make fast = true in GetStackTraceWithPcBpAndContext
on SANITIZER_FREEBSD and SANITIZER_NETBSD and can be done explicitly.
llvm-svn: 313517
Summary:
This change starts differentiating tail exits from normal exits. We also
increase the version number of the "naive" log to version 2, which will
be the starting version where these records start appearing. In FDR mode
we treat the tail exits as normal exits, and are thus subject to the
same treatment with regard to record unwriting.
Updating the version number is important to signal older builds of the
llvm-xray tool that do not deal with the tail exit records must fail
early (and that users should only use the llvm-xray tool built after
the support for tail exits to get accurate handling of these records).
Depends on D37964.
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37965
llvm-svn: 313515
Francis Ricci