Many targets have already migrated to the per-target runtime directory
layout, which is generally preferred. For AIX however, we are currently
using per-target runtime directories by default for some runtimes (i.e.
`flang-rt`) but not others. This change makes things consistent for
other runtimes (most primarily `compiler-rt`) as well, adopting the
layout uniformly for the AIX target.
This change also normalizes the triple used for building compiler-rt to
remove any OS version number, as there is currently no need to version
the runtimes this way and the driver code doesn't expect this anyhow.
Have the warning suppression apply only to the code that is currently
affected. The suppression is guarded via preprocessor conditions to
cases where it is tested and known to be needed.
Issue: https://github.com/llvm/llvm-project/issues/138916
Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com>
On ARM64EC, function names and calls (but not address-taking or data
symbol references) use symbols prefixed with "#". Since it's an unique
behavior, introduce a new `FUNC_SYMBOL` macro instead of reusing
something like `SYMBOL_NAME`, which is also used for data symbols.
Based on patch by Billy Laws.
This patch introduces a new optional CMake flag:
COMPILER_RT_EXCLUDE_LIBC_PROVIDED_ARM_AEABI_BUILTINS
When enabled, this flag excludes the following ARM AEABI memory function
implementations from the compiler-rt build:
__aeabi_memcmp
__aeabi_memset
__aeabi_memcpy
__aeabi_memmove
These functions are already provided by standard C libraries like glibc,
newlib, and picolibc, so excluding them avoids duplicate symbol
definitions and reduces unnecessary code duplication.
Note:
- libgcc does not define the __aeabi_* functions that overlap with those
provided by the C library. Enabling this option makes compiler-rt behave
consistently with libgcc.
- This prevents duplicate symbol errors when linking, particularly in
bare-metal configurations where compiler-rt is linked first.
- This flag is OFF by default, meaning all AEABI memory builtins will
still be built unless explicitly excluded.
This change is useful for environments where libc provides runtime
routines, supporting more minimal, conflict free builds.
Sanitizers using this hook on Fuchsia can define this function to do any
extra stuff at the end of the startup hook. For now this is only used by
HWASan which needs to explicitly be initialized before libc extensions
are intitialized.
On 64-bit platforms, libgcc doesn't ship with __clzsi2, so __builtin_clz
gets lowered to __clzdi2. A check already exists for GCC, but as of
commit 8210ca019839fc5430b3a95d7caf5c829df3232a clang also lowers
__builtin_clz to __clzdi2 on sparc64.
Update the check so that building __clzdi2 with clang/sparc64 also
works.
10s looks not enough. With highly parallel test
execution on VMs it's very possible that Asan
report will have no enough time to produce output.
I can reproduce locally 1s is not always enough,
but likely my workstation is faster then buildbot.
Additionally, don't use puts/CHECK to validate
timeout. We can exit with 0 and it should violate
"not" expectation.
Follow up to #131756.
'list.size()' is determined at runtime, so using static_assert on it as
suggested by the TODO comment is not feasible and produces the following
error when done:
error: static assertion expression is not an integral constant
expression
initially referenced in https://github.com/bitcoin/bitcoin/pull/32024
Co-authored-by: Chand-ra <chandrapratap376@gmail.com>
This makes sure that COMPILER_RT_ARMHF_TARGET is set properly for
targets without a specific "armhf" target name, such as armv7 windows.
This fixes the builtins test comparesf2_test.c on Windows on armv7.
Compiler-rt libraries on arm use "arm" or "armhf" as suffix, not the
full exact arch name like "armv7".
This matches what was done for the build system in
8e11bede3a6ac11ebcc05c82fac39899feaf9534, to match the names that Clang
expects (in getArchNameForCompilerRTLib in Clang).
This fixes building a large number of the compiler-rt tests for
Windows/armv7.
This avoids building asan when targeting Windows on armv7 or aarch64. It
is possible to build asan successfully for those configurations (since
5ea9dd8c7076270695a1d90b9c73718e7d95e0bf and
0c391133c9201ef29273554a1505ef855ce17668), but asan isn't functional
there.
This change skips building asan for targets other than x86_32 and
x86_64.
By excluding asan from the build, we fix the "check-ubsan" target for
armv7 and aarch64 Windows. If asan is included in the build, an
ubsan-asan configuration gets added to the tests, and as asan isn't
functional for these targets, it produces a lot of test failures even
when just trying to run "check-ubsan".
This removes a leftover workaround from
00f3f6e296d49eb261e1ad47868a50122bfc111e from 2016. Currently the tests
seem to work fine on x86_64 in both MSVC and mingw configurations with
this workaround removed.
(On aarch64, asan isn't functional at all; this workaround used to hide
that issue when running "check-ubsan", but the issue is apparent if
running all tests with "check-compiler-rt" anyway.)
Same approach as in Asan.
Now it's going to print:
```
Failed Tests (2):
UBSan-Minimal-i386-linux :: TestCases/icall.c
UBSan-Minimal-x86_64-linux :: TestCases/icall.c
```
Before it was:
```
Failed Tests (2):
UBSan-Minimal-x86_64 :: TestCases/icall.c
UBSan-Minimal-x86_64 :: TestCases/icall.c
```
PR #131756 introduced a patch to fix a deadlock between LSan and ASan.
The relevant deadlock only occurs when LSan is enabled and
`dl_iterate_phdr` is used for Stop-the-World, i.e., under the condition
`CAN_SANITIZE_LEAKS && (SANITIZER_LINUX || SANITIZER_NETBSD)`.
Therefore, this commit also sets the effective condition of this patch
to the above condition, avoiding unnecessary problems in other
environments, e.g., stack overflow on MSVC/Windows.
This PR is based on my last PR #132752 (the first commit of this PR),
but addressing a different issue.
This commit addresses the limitation in `PointerMayBeCaptured` analysis
when dealing with derived pointers (e.g. arr+1) as described in issue
#132739.
The current implementation of `PointerMayBeCaptured` may miss captures
of the underlying `alloca` when analyzing derived pointers, leading to
some FNs in TSan, as follows:
```cpp
void *Thread(void *a) {
((int*)a)[1] = 43;
return 0;
}
int main() {
int Arr[2] = {41, 42};
pthread_t t;
pthread_create(&t, 0, Thread, &Arr[0]);
// Missed instrumentation here due to the FN of PointerMayBeCaptured
Arr[1] = 43;
barrier_wait(&barrier);
pthread_join(t, 0);
}
```
Refer to this [godbolt page](https://godbolt.org/z/n67GrxdcE) to get the
compilation result of TSan.
Even when `PointerMayBeCaptured` working correctly, it should backtrack
to the original `alloca` firstly during analysis, causing redundancy to
the outer's `findAllocaForValue`.
```cpp
const AllocaInst *AI = findAllocaForValue(Addr);
// Instead of Addr, we should check whether its base pointer is captured.
if (AI && !PointerMayBeCaptured(Addr, true)) ...
```
Key changes:
Directly analyze the capture status of the underlying `alloca` instead
of derived pointers to ensure accurate capture detection
```cpp
const AllocaInst *AI = findAllocaForValue(Addr);
// Instead of Addr, we should check whether its base pointer is captured.
if (AI && !PointerMayBeCaptured(AI, true)) ...
```
I'm trying to put together an LLVM built toolchain (including LLVM libc)
targeting UEFI, currently I get an error saying "Unknown target". This
PR enables compiling compiler-rt for UEFI.
- _Float16 is now accepted by Clang.
- The half IR type is fully handled by the backend.
- These values are passed in FP registers and converted to/from float around
each operation.
- Compiler-rt conversion functions are now built for s390x including the missing
extendhfdf2 which was added.
Fixes#50374
[compiler-rt] The test `addtf3_test.c` is currently guarded by `#if
defined(CRT_HAS_IEEE_TF)`, a macro that is declared in `int_lib.h`.
However, `int_lib.h` is included *after* the preprocessor check, which
results in the macro not being defined in time and causes the test to
always be skipped.
This patch moves the includes of `fp_test.h` and `int_lib.h` to the top
of the file so that `CRT_HAS_IEEE_TF` is defined before it is checked.
Co-authored-by: Kostiantyn Lazukin <koslaz01@ip-10-252-21-142.eu-west-1.compute.internal>
### Description
This PR resolves a deadlock between AddressSanitizer (ASan) and
LeakSanitizer (LSan)
that occurs when both sanitizers attempt to acquire locks in conflicting
orders across
threads. The fix ensures safe lock acquisition ordering by preloading
module information
before error reporting.
---
### Issue Details
**Reproducer**
```cpp
// Thread 1: ASan error path
int arr[1] = {0};
std::thread t([&]() {
arr[1] = 1; // Triggers ASan OOB error
});
// Thread 2: LSan check path
__lsan_do_leak_check();
```
**Lock Order Conflict**:
- Thread 1 (ASan error reporting):
1. Acquires ASan thread registry lock (B)
1. Attempts to acquire libdl lock (A) via `dl_iterate_phdr`
- Thread 2 (LSan leak check):
1. Acquires libdl lock (A) via `dl_iterate_phdr`
1. Attempts to acquire ASan thread registry lock (B)
This creates a circular wait condition (A -> B -> A) meeting all four
Coffman deadlock criteria.
---
### Fix Strategy
The root cause lies in ASan's error reporting path needing
`dl_iterate_phdr` (requiring lock A)
while already holding its thread registry lock (B). The solution:
1. **Preload Modules Early**: Force module list initialization _before_
acquiring ASan's thread lock
2. **Avoid Nested Locking**: Ensure symbolization (via dl_iterate_phdr)
completes before error reporting locks
Key code change:
```cpp
// Before acquiring ASan's thread registry lock:
Symbolizer::GetOrInit()->GetRefreshedListOfModules();
```
This guarantees module information is cached before lock acquisition,
eliminating
the need for `dl_iterate_phdr` calls during error reporting.
---
### Testing
Added **asan_lsan_deadlock.cpp** test case:
- Reproduces deadlock reliably without fix **under idle system
conditions**
- Uses watchdog thread to detect hangs
- Verifies ASan error reports correctly without deadlock
**Note**: Due to the inherent non-determinism of thread scheduling and
lock acquisition timing,
this test may not reliably reproduce the deadlock on busy systems (e.g.,
during parallel
`ninja check-asan` runs).
---
### Impact
- Fixes rare but severe deadlocks in mixed ASan+LSan environments
- Maintains thread safety guarantees for both sanitizers
- No user-visible behavior changes except deadlock elimination
---
### Relevant Buggy Code
- Code in ASan's asan_report.cpp
```cpp
explicit ScopedInErrorReport(bool fatal = false)
: halt_on_error_(fatal || flags()->halt_on_error) {
// Acquire lock B
asanThreadRegistry().Lock();
}
~ScopedInErrorReport() {
...
// Try to acquire lock A under holding lock B via the following path
// #4 0x000071a353d83e93 in __GI___dl_iterate_phdr (
// callback=0x5d1a07a39580 <__sanitizer::dl_iterate_phdr_cb(dl_phdr_info*, unsigned long, void*)>,
// data=0x6da3510fd3f0) at ./elf/dl-iteratephdr.c:39
// #5 0x00005d1a07a39574 in __sanitizer::ListOfModules::init (this=0x71a353ebc080)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:784
// #6 0x00005d1a07a429e3 in __sanitizer::Symbolizer::RefreshModules (this=0x71a353ebc058)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_libcdep.cpp:188
// #7 __sanitizer::Symbolizer::FindModuleForAddress (this=this@entry=0x71a353ebc058,
// address=address@entry=102366378805727)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_libcdep.cpp:214
// #8 0x00005d1a07a4291b in __sanitizer::Symbolizer::SymbolizePC (this=0x71a353ebc058, addr=102366378805727)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_libcdep.cpp:88
// #9 0x00005d1a07a40df7 in __sanitizer::(anonymous namespace)::StackTraceTextPrinter::ProcessAddressFrames (
// this=this@entry=0x6da3510fd520, pc=102366378805727)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp:37
// #10 0x00005d1a07a40d27 in __sanitizer::StackTrace::PrintTo (this=this@entry=0x6da3510fd5e8,
// output=output@entry=0x6da3510fd588)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp:110
// #11 0x00005d1a07a410a1 in __sanitizer::StackTrace::Print (this=0x6da3510fd5e8)
// at llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_stacktrace_libcdep.cpp:133
// #12 0x00005d1a0798758d in __asan::ErrorGeneric::Print (
// this=0x5d1a07aa4e08 <__asan::ScopedInErrorReport::current_error_+8>)
// at llvm-project/compiler-rt/lib/asan/asan_errors.cpp:617
current_error_.Print();
...
}
```
- Code in LSan's lsan_common_linux.cpp
```cpp
void LockStuffAndStopTheWorld(StopTheWorldCallback callback,
CheckForLeaksParam *argument) {
// Acquire lock A
dl_iterate_phdr(LockStuffAndStopTheWorldCallback, ¶m);
}
static int LockStuffAndStopTheWorldCallback(struct dl_phdr_info *info,
size_t size, void *data) {
// Try to acquire lock B under holding lock A via the following path
// #3 0x000055555562b34a in __sanitizer::ThreadRegistry::Lock (this=<optimized out>)
// at llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:99
// #4 __lsan::LockThreads () at llvm-project/compiler-rt/lib/asan/asan_thread.cpp:484
// #5 0x0000555555652629 in __lsan::ScopedStopTheWorldLock::ScopedStopTheWorldLock (this=<optimized out>)
// at llvm-project/compiler-rt/lib/lsan/lsan_common.h:164
// #6 __lsan::LockStuffAndStopTheWorldCallback (info=<optimized out>, size=<optimized out>, data=0x0,
// data@entry=0x7fffffffd158) at llvm-project/compiler-rt/lib/lsan/lsan_common_linux.cpp:120
ScopedStopTheWorldLock lock;
DoStopTheWorldParam *param = reinterpret_cast<DoStopTheWorldParam *>(data);
StopTheWorld(param->callback, param->argument);
return 1;
}
```
Because of the nature of this test (mmap stress-test) it tests too large
of memory allocations to be stable on watchos. WatchOS has memory limits
that can lead to the termination of this process before it reaches the
limit set by the flag. Typical only on devices that are under heavy
load. disable on watchOS.
rdar://147222346
Functions with `musttail` calls can't be roots because we can't instrument their `ret` to release the context. This patch tags their `CtxRoot` field in their `FunctionData`. In compiler-rt we then know not to allow such functions become roots, and also not confuse `CtxRoot == 0x1` with there being a context root.
Currently we also lose the context tree under such cases. We can, in a subsequent patch, have the root detector search past these functions.
Fixes:
```
[6113/7139] Building CXX object projects\compiler-rt\lib\interception\CMakeFiles\RTInterception.x86_64.dir\interception_win.cpp.obj
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough]
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): note: insert 'FALLTHROUGH;' to silence this warning
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
| FALLTHROUGH;
C:\git\llvm-project\compiler-rt\lib\interception\interception_win.cpp(746,5): note: insert 'break;' to avoid fall-through
746 | case 0xB841: // 41 B8 XX XX XX XX : mov r8d, XX XX XX XX
| ^
| break;
1 warning generated.
```
