It broke the build:
compiler-rt/lib/hwasan/hwasan_thread.cpp:177:11: error: unknown type name 'ssize_t'; did you mean 'size_t'?
177 | (ssize_t)unique_id_, (void *)this, (void *)stack_bottom(),
| ^~~~~~~
| size_t
> This change addresses CodeQL format-string warnings across multiple
> sanitizer libraries by adding explicit casts to ensure that printf-style
> format specifiers match the actual argument types.
>
> Key updates:
> - Cast pointer arguments to (void*) when used with %p.
> - Use appropriate integer types and specifiers (e.g., size_t -> %zu,
> ssize_t -> %zd) to avoid mismatches.
> - Fix format specifier mismatches across xray, memprof, lsan, hwasan,
> dfsan.
>
> These changes are no-ops at runtime but improve type safety, silence
> static analysis warnings, and reduce the risk of UB in variadic calls.
This reverts commit d3d5751a39452327690b4e011a23de8327f02e86.
Win/ASan relies on the runtime's functions being 16-byte aligned so it
can intercept them with hotpatching. This used to be true (but not
guaranteed) until #149444.
Passing /hotpatch will give us enough alignment and generally ensure
that the functions are hotpatchable.
This change addresses CodeQL format-string warnings across multiple
sanitizer libraries by adding explicit casts to ensure that printf-style
format specifiers match the actual argument types.
Key updates:
- Cast pointer arguments to (void*) when used with %p.
- Use appropriate integer types and specifiers (e.g., size_t -> %zu,
ssize_t -> %zd) to avoid mismatches.
- Fix format specifier mismatches across xray, memprof, lsan, hwasan,
dfsan.
These changes are no-ops at runtime but improve type safety, silence
static analysis warnings, and reduce the risk of UB in variadic calls.
The change in PR #154268 introduced a dependency on the `__GLIBC_PREREQ`
macro, which is not defined in musl libc. This caused the build to fail
in environments using musl.
This patch fixes the build by including
`sanitizer_common/sanitizer_glibc_version.h`. This header provides a
fallback definition for `__GLIBC_PREREQ` when LLVM is built against
non-glibc C libraries, resolving the compilation error.
LSan was recently refactored to call GetMaxUserVirtualAddress for
diagnostic purposes. This leads to failures for some of our downstream
tests which only run with lsan. This occurs because
GetMaxUserVirtualAddress depends on setting up shadow via a call to
__sanitizer_shadow_bounds, but shadow bounds aren't set for standalone
lsan because it doesn't use shadow. This updates the function to invoke
the same syscall used by __sanitizer_shadow_bounds calls for getting the
memory limit. Ideally this function would only be called once since we
only need to get the bounds once.
More context in https://fxbug.dev/437346226.
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
On glibc x86-64, functions like pthread_cond_init exist in two versions:
2.2 (older pthread_cond_t) and 2.3.2 (newer pthread_cond_t). In glibc
versions prior to 2.36, using an unversioned interceptor
(`dlsym(RTLD_NEXT, "pthread_cond_init")`) retrieves the older 2.2
symbol, which is not desired
(https://sourceware.org/bugzilla/show_bug.cgi?id=14932).
For newer architectures, such as aarch64 (introduced in glibc 2.17) and
riscv64 (introduced in glibc 2.27), a versioned interceptor is
unnecessary.
Pull Request: https://github.com/llvm/llvm-project/pull/154268
Currently HwASan has no fiber switch interface for coroutines. This PR
adds fiber switch interfaces similar to ASan which helps to pass sp
check correctly on unwinding.
The only difference is HwASan does not need a fake stack since tags can
do the same thing (e.g., detect UAR). Interfaces are made identical with
ASan's.
Also adds unit test which is similar to ASan with minor adjustments:
1. change `__asan_handle_no_return` to `__hwasan_handle_vfork`
2. remove huge stack test since `__hwasan_handle_vfork` has no stack
size limitation.
3. use uninstrumented globals to simulate allocation since hwasan do not
support tagged pointer while using `longjmp`
The testcase is tested on both x86 with alias mode enabled and aarch64.
This can happen when JIT code is run, and we can't symbolize those
frames, but they should remain numbered in the stack. An example
spidermonkey trace:
```
#0 0x564ac90fb80f (/builds/worker/dist/bin/js+0x240e80f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#1 0x564ac9223a64 (/builds/worker/dist/bin/js+0x2536a64) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#2 0x564ac922316f (/builds/worker/dist/bin/js+0x253616f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#3 0x564ac9eac032 (/builds/worker/dist/bin/js+0x31bf032) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#4 0x0dec477ca22e (<unknown module>)
```
Without this change, the following symbolization is output:
```
#0 0x55a6d72f980f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x55a6d72f980f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x55a6d7421a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x55a6d742116f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x55a6d80aa032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#4 0x2c803bd8f22e (<unknown module>)
```
The last frame has a duplicate number. With this change the numbering is
correct:
```
#0 0x5620c58ec80f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x5620c58ec80f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x5620c5a14a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x5620c5a1416f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
#4 0x5620c669d032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
#5 0x349f24c7022e (<unknown module>)
```
It's a followup to https://github.com/llvm/llvm-project/pull/154189 ,
which broke test on android bot. Making sure XFAIL only happen on darwin
bots
rdar://158543555
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
Poisoning of C++ array redzones is only implemented for x86 CPUs. New
arm64 bots are being brought up, where these test fail.
Original C++ arrays shadow poisoning change:
http://reviews.llvm.org/D4774
rdar://158025391
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
This reverts commit cf002847a464c004a57ca4777251b1aafc33d958 i.e.,
relands ba603b5e4d44f1a25207a2a00196471d2ba93424. It was reverted
because it was subtly wrong: multiplying an uninitialized zero should
not result in an initialized zero.
This reland fixes the issue by using instrumentation analogous to
visitAnd (bitwise AND of an initialized zero and an uninitialized value
results in an initialized value). Additionally, this reland expands a
test case; fixes the commit message; and optimizes the change to avoid
the need for horizontalReduce.
The current instrumentation has false positives: it does not take into
account that multiplying an initialized zero value with an uninitialized
value results in an initialized zero value This change fixes the issue
during the multiplication step. The horizontal add step is modeled using
bitwise OR.
Future work can apply this improved handler to the AVX512 equivalent
intrinsics (x86_avx512_pmaddw_d_512, x86_avx512_pmaddubs_w_512.) and AVX
VNNI intrinsics.
With gcc 15 we end up emitting a reference to the
std::__glibcxx_assert_fail function because of this change:
361d230fd7
combined with assertion checks in the std::atomic implementation.
This reference is undefined with dfsan causing the test to fail. Fix it
by defining the macro that disables assertions.
Pull Request: https://github.com/llvm/llvm-project/pull/153873
This makes the tests pass on my AArch64 machine with 16K pages.
Not sure why some of the AArch64-specific test failures don't seem to
occur on sanitizer-aarch64-linux. I could also reproduce them by running
buildbot_cmake.sh on my machine.
Pull Request: https://github.com/llvm/llvm-project/pull/153860
This currently generates many linker warnings of this form, due to
defining mem(cpy|move|set) in every object file:
```
ld: warning: '.../build/projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.ios.dir/interception_linux.cpp.o' has malformed LC_DYSYMTAB, expected 6 undefined symbols to start at index 1, found 3 undefined symbols starting at index 1
```
In order for this to actually replace these symbols on mach-o, they
would need a leading underscore, e.g. `.set _memcpy,
___sanitizer_internal_memcpy`. However doing so does not fix the
warnings, and furthermore it ends up replacing `REAL(memcpy)` calls with
`__sanitizer_internal_memcpy` in places such as
`__asan::Allocator::Reallocate`. There is no way on Apple platforms to
recreate the intended behaviour, so let's just disable this on them to
reduce warning noise.
rdar://123771479
Since we (Linaro) moved out bots to a new machine, this test has been
failing:
https://lab.llvm.org/buildbot/#/builders/121/builds/1566
Most of the time, the rss difference is greater than 512 on the first
iteration then settles down to 512 for all the rest.
```
starting rss 512
shadow pages: 1024
p = 0xe083e0800000
1536 -> 740
diff 796
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
1252 -> 740
diff 512
p = 0xe083e0800000
passed 1 out of 10
release-shadow.c.tmp: /home/tcwg-buildbot/worker/clang-aarch64-lld-2stage/llvm/compiler-rt/test/hwasan/TestCases/Linux/release-shadow.c:81: int main(): Assertion `success_count > total_count * 0.8' failed.
```
Given that the test was looking for a diff of at least 513, I guess that
512 is ok too.
For future reference, the original bot host was running this kernel:
Linux 5.15.0-136-generic #147-Ubuntu SMP Sat Mar 15 15:51:36 UTC 2025
aarch64 aarch64 aarch64 GNU/Linux
And the new host:
Linux 6.8.0-64-generic #67-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 15
20:23:40 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux
Though the new host also has more RAM, so the kernel may be less
aggresive with memory management.
Contrary to most testcases in the libFuzzer test suite,
`focus-function.test` seems to lack the `%run` directives, which is an
inconvenience in cases when `%run` actually gets substituted for
something. This PR adds said directives.
The compiler-rt build gradually learned to target arm64e. With that, we
build builtins for arm64e, but running their tests usually isn't
possible, because most versions of macOS so far restrict arm64e (on
account of its unstable ABI).
Starting with macOS 26, arm64e executables can be run, because the
aligned linker automatically targets ptrauth ABI version 1. Without
that, (at ABI version 0) these can't be executed.
We can't rely or require new linkers (and we elsewhere explicitly
fallback to ld classic anyway), so in the meantime one way to execute
these would be to explicitly ask for ABI version 1, which we generally
try to avoid, and don't support in our llvm (which unconditionally
targets ABI version 0).
This is also an uncommon situation; sanitizer runtime tests aren't run
on arm64e today, because we haven't listed arm64e as a supported arch
yet.
Everything other than builtins also tests for execution in cmake first;
we should consider that, but it has its own problems.
So we can simply disable arm64e from tests, by filtering it out as a
valid darwin host arch, which accurately reflects reality.
When we try to add arm64e sanitizer runtime build and test support,
we'll want to change that, but that's a bigger problem than builtins.
This reverts commit 29ad073c6c325dbf92c1aa5a285ca48e55cb918b i.e.,
relands 927e19f5f3b357823f86f6c4f1378abedccadf27.
It was reverted because of buildbot breakages. This reland adds
"-pthread" and also moves the test to Posix-only.
Original commit message:
ASan's instrumentation pass uses
`ASanStackFrameLayout::ComputeASanStackFrameLayout()` to calculate the
offset of variables, taking into account alignment. However, the fake
stack frames returned by the runtime's `GetFrame()` are not guaranteed
to be sufficiently aligned (and in some cases, even guaranteed to be
misaligned), hence the offset addresses may sometimes be misaligned.
This change fixes the misalignment issue by padding the FakeStack. Every
fake stack frame is guaranteed to be aligned to the size of the frame.
The memory overhead is low: 64KB per FakeStack, compared to the
FakeStack size of ~700KB (min) to 11MB (max).
Updates the test case from
https://github.com/llvm/llvm-project/pull/152889.
Reverts llvm/llvm-project#147422
Seems to be causing problems with tracebacks. Probably the trackback
code doesn't know how to switch back to the regular stack after it gets
to the top of the signal stack.
Changes:
Apple only:
* Move OutputReport (and thus symbolization) after the locked region when reporting.
* ScopedReportBase constructor requires the thread_registry lock to be held, so the regions where ScopedReports get created must be inside the locked region.
* Bail early from MemoryAccess if we are symbolizing.
Other platforms should behave as before, outputting reports while the locks are held.
This is a follow up to https://github.com/llvm/llvm-project/pull/151120,
which delayed symbolization of ScopedReports.
rdar://152829396
ASan's instrumentation pass uses `ASanStackFrameLayout::ComputeASanStackFrameLayout()` to calculate the offset of variables, taking into account alignment. However, the fake stack frames returned by the runtime's `GetFrame()` are not guaranteed to be sufficiently aligned (and in some cases, even guaranteed to be misaligned), hence the offset addresses may sometimes be misaligned.
This change fixes the misalignment issue by padding the FakeStack. Every fake stack frame is guaranteed to be aligned to the size of the frame.
The memory overhead is low: 64KB per FakeStack, compared to the FakeStack size of ~700KB (min) to 11MB (max).
Updates the test case from https://github.com/llvm/llvm-project/pull/152889.
This test case demonstrates that ASan does not currently align FakeStack frames correctly:
- for 4KB objects on a 64KB stack, alignment is deterministically incorrect
- for objects larger than 4KB, even with large stack sizes, alignment is not guaranteed
https://github.com/llvm/llvm-project/pull/152819 will fix it.
As a consequence of the ASAN DLL's initialization process on Windows,
some flags defined by the user through overriding the
__asan_default_options() method will not be honored. More information
here: [#117925](https://github.com/llvm/llvm-project/issues/117925)
This PR aims to alleviate this for the symbolize flag in relation to
this user's concern
[here.](https://developercommunity.visualstudio.com/t/Overloading-of-__asan_default_options-/10688871)
1. Declared `Symbolizer::ClearTools()`.
2. Defined `Symbolizer::ClearTools()`. Upon invocation of the weak
function callback of `__asan_default_options()`, `Symbolizer::tools_`
will be cleared if the user specifies `symbolize=0`.
3. Added tests.
---------
Co-authored-by: MacGyver Codilla <mcodilla@microsoft.com>
SA_ONSTACK is required for certain runtimes that use small stacks, for
instance the Go runtime.
See https://github.com/golang/go/issues/49075
SA_ONSTACK is a no-op unless someone also calls sigaltstack.
No behavioral change, but eliminates potential UB in strict-alignment
systems.
The previous commit (llvm#94171) bulk-updated alignment usage to C++23
spec, but missed this occurrence.
https://github.com/llvm/llvm-project/pull/152192 forgot to make the
argument changes to Android code in UBsan minimal causing a build error
for Android LLVM:
```
/b/f/w/src/git/out/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:102:3: error: no matching function for call to 'format_msg'
102 | format_msg(kind, caller, msg_buf, msg_buf + sizeof(msg_buf));
| ^~~~~~~~~~
/b/f/w/src/git/out/llvm-project/compiler-rt/lib/ubsan_minimal/ubsan_minimal_handlers.cpp:37:13:
note: candidate function not viable: requires 5 arguments, but 4 were
provided
37 | static void format_msg(const char *kind, uintptr_t caller,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
38 | const uintptr_t *address, char *buf,
const char *end) {
```
This change adds the address argument to abort_with_message just like
__ubsan_report_error_fatal so it can be passed to format_msg.
This adds commentary to explain why ASan does not work for AArch64
non-Android Linux with 39-bit and 42-bit VMAs (e.g.,
https://github.com/llvm/llvm-project/issues/145259).
Additionally, it updates the 42-bit VMA shadow map comment, which has
been outdated for the last 10 years
(18b2258c92df93c83bc7fce94c20baff3c06e2c6 changed 39-bit and 42-bit to
use the same offset), and adds a comment for the 48-bit VMA shadow map.
+ Changed type_mismatch minimal handler to accept and print pointer.
This will allow to distinguish null pointer use, misallignment and
incorrect object size.
The change increases binary size by ~1% and has almost no performance
impact.
Fixes#149943
There is an issue tracking lsan incompatibility on these platforms:
https://github.com/llvm/llvm-project/issues/131678. Many of these tests
are currently failing and creating CI noise.
rdar://157252316
Fixes corner cases of https://github.com/llvm/llvm-project/pull/151406:
- Don't run TestPTrace() on SPARC, because internal_fork() on SPARC
actually calls __fork(). We can't safely __fork(), because it's possible
seccomp has been configured to disallow fork() but allow clone().
- if internal_fork() fails for whatever reason, we shouldn't give up. It
is strictly worse to give up early than to attempt StopTheWorld.
Also updates some comments/TODOs.
