When building hwasan on aarch64, the DT_AARCH64_BTI_PLT flag is missing
from libclang_rt.hwasan.so because some object files without
DT_AARCH64_BTI_PLT are linked in the final DSO.
These files are specific to riscv64 and x86_64, ending up with no
aarch64 code in them.
Avoid building and linking architecture-specific files unless the
architecture is listed in HWASAN_SUPPORTED_ARCH.
Currently we will not build float16/bfloat16 builtins on apple
platforms, LLVM will include calls to those builtins and fail to link.
I copied the test code we perform for non apple platforms because oddly
we branch on it being apple for building builtins
This reverts commit 7cf84d3b0bc5eda3a907dfd026d51a17e28114a3.
(llvmorg-19-init-14939-g7cf84d3b0bc5)
This has my wrong assumptions possibly. This was failing fuchsia.
Without this patch compiler-rt ubsan library has a bug displaying
incorrect values for variables of the _BitInt (previously called
_ExtInt) type. This patch affects affects both: generation of metadata
inside code generator and runtime part. The runtime part provided only
for i386 and x86_64 runtimes. Other runtimes should be updated to take
full benefit of this patch.
The patch is constructed the way to be backward compatible and int and
float type runtime diagnostics should be unaffected for not yet updated
runtimes.
This patch fixes issue:
https://github.com/llvm/llvm-project/issues/64100.
Co-authored-by: Vladislav Aranov <vladislav.aranov@ericsson.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
This diff contains the compiler-rt changes / preparations for nsan.
Test plan:
1. cd build/runtimes/runtimes-bins && ninja check-nsan
2. ninja check-all
Initially, the scudo allocator would return an error if the user
attempted to set the cache capacity
(i.e. the number of possible entries in the cache) above the maximum
cache capacity.
Now the allocator will resort to using the maximum cache capacity in
this event.
An error will still be returned if the user attempts to set the number
of entries to a negative value.
Commit 8306968b592d942cc49bde2e387061e673a9fbb7 deleted file
`compiler-rt/lib/memprof/memprof_meminfoblock.h`, but didn't remove it
from MEMPROF_HEADERS in `compiler-rt/lib/memprof/CMakeLists.txt`.
Remove unneeded leftover line in
`compiler-rt/lib/memprof/CMakeLists.txt`.
p.s.
GH #54777 reported a llvm14 build failure due to the existence of the
leftover line, but I'm unable to reproduce the build failure with llvm19
trunk.
By storing possible test vectors instead of combinations of conditions,
the restriction is dramatically relaxed.
This introduces two options to `cc1`:
* `-fmcdc-max-conditions=32767`
* `-fmcdc-max-test-vectors=2147483646`
This change makes coverage mapping, profraw, and profdata incompatible
with Clang-18.
- Bitmap semantics changed. It is incompatible with previous format.
- `BitmapIdx` in `Decision` points to the end of the bitmap.
- Bitmap is packed per function.
- `llvm-cov` can understand `profdata` generated by `llvm-profdata-18`.
RFC:
https://discourse.llvm.org/t/rfc-coverage-new-algorithm-and-file-format-for-mc-dc/76798
--
Change(s) since llvmorg-19-init-14288-g7ead2d8c7e91
- Update compiler-rt/test/profile/ContinuousSyncMode/image-with-mcdc.c
MacOS 15.0 and iOS 18.0 added a new sysctl to fetch a bitvector of all
the hw.optional.arm.FEAT_*'s in one go. Using this has a perf advantage
over doing multiple round-trips to the kernel and back, but since it's
not present in older oses, we still need the slow fallback.
This was reverted in https://github.com/llvm/llvm-project/pull/95435
because it broke Android static hwasan binaries. This reland limits the
change to !SANITIZER_ANDROID.
Original commit message:
When set to non-zero, the HWASan runtime will map the shadow base at the
specified constant address.
This is particularly useful in conjunction with the existing compiler
option 'hwasan-mapping-offset', which bakes a hardcoded constant address
into the instrumentation.
---------
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
When an uninstrumented libatomic is used with a TSan instrumented
memcpy, TSan may report a data race in circumstances where writes are
arguably safe.
This occurs because __atomic_compare_exchange won't be instrumented in
an uninstrumented libatomic, so TSan doesn't know that the subsequent
memcpy is race-free.
On the other hand, pthread_mutex_(un)lock will be intercepted by TSan,
meaning an uninstrumented libatomic will not report this false-positive.
pthread_mutexes also may try a number of different strategies to acquire
the lock, which may bound the amount of time a thread has to wait for a
lock during contention.
While pthread_mutex_lock has a larger overhead (due to the function call
and some dispatching), a dispatch to libatomic already predicates a lack
of performance guarantees.
It broke tests on Mac, see comment on the PR.
> Use more flexable regex ([0-9]+) for frame number checks. Since the
> frame numbers might change if some functions are not inlined.
>
> Similar to
> *
> 0360f3218a
> *
> 404bc5ca2a
This reverts commit 98174fb6ec9784d9eb7be313ee1317ca6e703d90
and the follow-up commit 86d8aec97fd9e009e9b360ffeee744d3acce730d.
To detect features we either use HWCAPs or directly extract system
register bitfields and compare with a value. In many cases equality
comparisons give wrong results for example FEAT_SVE is not set if SVE2
is available (see the issue #93651). I am also making the access to
__aarch64_cpu_features atomic.
The corresponding PR for the ACLE specification is
https://github.com/ARM-software/acle/pull/322.
When running some tests with --gtest_repeat=100 --gtest_shuffle, I
encountered some problems because the allocator wasn't torn down
completely, and the singleton pointer ended up pointing to a
use-after-scope'd object.
This patch has a couple of fixes and niceties:
1. Removing the once-init stuff from tests, now that it's implicitly
done in GuardedPoolAllocator::installAtFork() anyway.
2. Calling uninitTestOnly() in the late_init test.
3. Resetting the HasReportedBadPoolAccess when the signal handlers are
installed (allowing for --gtest_repeat w/ recoverable mode).
4. Adding a check and resetting the singleton pointer in
uninitTestOnly().
Use more flexable regex ([0-9]+) for frame number checks. Since the
frame numbers might change if some functions are not inlined.
Similar to
*
0360f3218a
*
404bc5ca2a
Add missing __DATA sections that the objc runtime expects to register.
This fixes running objc code that makes use of `@protocol` references
and `__attribute__((objc_nonlazy_class))` classes.
rdar://129368761
BytesInBG is always greater or equal to BG->BytesInBGAtLastCheckpoint.
Note that the bug led to unnecessary attempts of page releasing and
doesn't have critical impact on the correctness.
`std::aligned_storage` is deprecated with C++23, see
[here](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1413r3.pdf).
This replaces the usages of `std::aligned_storage` within compiler-rt
with an aligned `std::byte` array.
I will provide patches for other subcomponents as well.
DFSan's sscanf is incorrect
(https://github.com/llvm/llvm-project/issues/94769), which results in
erroneous matches when scraping RSS from /proc/maps. This patch works
around the issue by using strstr as a secondary check.
It also adds a loose validity check for the initial RSS measurement, to
guard against regressions in get_rss_kb().
Fixes https://github.com/llvm/llvm-project/issues/91287
This test case shows a limitation of DFSan's sscanf implementation
(introduced in https://reviews.llvm.org/D153775): it simply ignores
ordinary characters in the format string, instead of actually comparing
them against the input. This may change the semantics of instrumented
programs.
Importantly, this also means that DFSan's release_shadow_space.c test,
which relies on sscanf to scrape the RSS from /proc/maps output, will
incorrectly match lines that don't contain RSS information. As a result,
it adding together numbers from irrelevant output (e.g., base
addresses), resulting in test flakiness
(https://github.com/llvm/llvm-project/issues/91287).
This function is called during very early startup and which can result
in a crash on FreeBSD. The sigaction() function in libc is indirected
via a table so that it can be interposed by the threading library
rather than calling the syscall directly. In the crash I was observing
this table had not yet been relocated, so we ended up jumping to an
invalid address. To avoid this problem we can call __sys_sigaction,
which calls the syscall directly and in FreeBSD 15 is part of libsys
rather than libc, so does not depend on libc being fully initialized.
…ty with high-entropy ASLR
With high-entropy ASLR (e.g., 32-bits == 16TB), the allocator base of
0x700000000000 (112TB) may collide with the placement of the libraries
(e.g., on Linux, the mmap base could be 128TB - 16TB == 112TB). This
results in a segfault in the test case.
This patch moves the allocator base below the PIE program segment,
inspired by fb77ca05ffb4f8e666878f2f6718a9fb4d686839. As per that patch:
1) we are leaving the old behavior for Apple 2) since ASLR cannot be set
above 32-bits for x86-64 Linux, we expect this new layout to be durable.
Note that this is only changing a test case, not the behavior of
sanitizers. Sanitizers have their own settings for initializing the
allocator base.
Reproducer:
1. ninja check-sanitizer # Just to build the test binary needed below;
no need to actually run the tests here
2. sudo sysctl vm.mmap_rnd_bits=32 # Increase ASLR entropy
3. for f in `seq 1 10000`; do echo $f;
GTEST_FILTER=*SizeClassAllocator64Dense
./projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-x86_64-Test
> /tmp/x; if [ $? -ne 0 ]; then cat /tmp/x; fi; done
