| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The initial check-in of compiler-rt/lib/nsan #94322 has a lot of style
issues. Fix them before the history becomes more useful.
Pull Request: https://github.com/llvm/llvm-project/pull/96142
|
|
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
|
|
in-place" (#95838)
Reland of #93212, which had been reverted in
commit bddd8eae17df6511aee789744ccdc158de817081.
|
|
(#95275)
https://github.com/llvm/llvm-project/pull/95275#issuecomment-2177366693
|
|
Configs that use `MapAllocatorNoCache` for its secondary cache will
return `false` if `setOption` is called with some [specific
options](https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/scudo/standalone/secondary.h#L104),
and this breaks with the `SecondaryOptions` test.
This change will gate testing all `setOption` expectations for cache
options only if the allocator cache is enabled. This will unblock
[github.com/llvm/llvm-project/pull/95595
](https://github.com/llvm/llvm-project/pull/95595) from merging into
Fuchsia.
|
|
Updated MapDynamicShadow callsite in asan_win.
|
|
Reverts llvm/llvm-project#95069
Broke windows bot
|
|
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.
|
|
|
|
FileOffsetToCounters. NFC.
|
|
|
|
(#95334)
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>
|
|
|
|
|
|
Fixes: #94769
|
|
Reverts llvm/llvm-project#73980
This broke static hwasan binaries in Android, for some reason the
fixed_shadow_base branch gets taken
|
|
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
> *
> https://github.com/llvm/llvm-project/commit/0360f3218a13666123849f6699216bdbebe64833
> *
> https://github.com/llvm/llvm-project/commit/404bc5ca2ae5fffa45d5240dcf52b7f134988867
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
*
https://github.com/llvm/llvm-project/commit/0360f3218a13666123849f6699216bdbebe64833
*
https://github.com/llvm/llvm-project/commit/404bc5ca2ae5fffa45d5240dcf52b7f134988867
|
|
is not supported (#94973)
This prevents build failures when building with `DISABLE_AARCH64_FMV`,
see https://github.com/llvm/llvm-project/pull/92921.
|
|
(#95144)
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.
|
|
in-place (#93212)"
This reverts commit 760d880ea602117aa2e6bba4cf31069f09225b4b.
It broke https://lab.llvm.org/buildbot/#/builders/169/builds/32309
|
|
(#93212)
|
|
(#94171)
`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
|
|
Otherwise, older copies of LLD may not understand the latest bitcode
versions (for example, if we increase
`ModuleSummaryIndex::BitCodeSummaryVersion`)
Related to
https://github.com/llvm/llvm-project/pull/90692#issuecomment-2113250317
|
|
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.
|
|
(#93234)
…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
|
|
These CHECKs are all checking indices, which must be strictly smaller
than the size (otherwise they would go out of bounds).
|
|
(#94374)"
This reverts commit b62b7a42bbee4a3bbf9094808f460fdc9c119bd7 and
a5729b71d844c1444f7d348dc2d4ea5b98de5ec5.
This commit broke compilation for systems that lack pthreads.
|
|
(#92921)
__arm_get_current_vg emits a cntd instruction if in streaming mode or SVE is
available at runtime, otherwise it will return 0.
|
|
PTHREAD_MUTEX_INITIALIZER is zeroes for glibc and musl, but it improves
conformance and might work with more libc implementations.
Follow-up to #94374
Pull Request: https://github.com/llvm/llvm-project/pull/94387
|
|
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.
|
|
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
|
|
https://github.com/llvm/llvm-project/commit/0e96eebc7f681a7ce41f35909e609c7c61a11455
accidentally turned the prior patch
(https://github.com/llvm/llvm-project/commit/57a507930b50c445140feb68bffe1c21af53319e)
into a no-op because this macro is always defined (as either 1 or 0).
This patch changes it to correctly use #if.
|
|
This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes #75490
Closes #53294 #23355
|
|
(#93787)
So far, these tests have been disabled in mingw build configurations
(built as asan-dynamic), but these were enabled in
246234ac70faa1e3281a2bb83dfc4dd206a7d59c, exposing the issue.
(That commit is currently reverted, but will probably be relanded in
some form soon.)
|
|
This reverts commit 8fa66c6ca7272268747835a0e86805307b62399c.
|
|
Re-Apply: 246234ac70faa1e3281a2bb83dfc4dd206a7d59c
Originally #81677
The static asan runtime on windows had various buggy hacks to ensure loaded dlls got the executable's copy of asan, these never worked all that well, so we have eliminated the static runtime altogether and made the dynamic runtime work for applications linking any flavor of the CRT.
Among other things this allows non-asan-instrumented applications to load asan-instrumented dlls that link against the static CRT.
Co-authored-by: Amy Wishnousky <amyw@microsoft.com>
|
