Looks good to me in principle. I'm wondering whether there could be situations where a signal stack has been established with sigaltstack but it's intended for some specific signal(s) only - if we were to set SA_ONSTACK uncontitionally, we would run all of the fuzzer's signal handlers on the signal stack. That said, none of the handlers seem to require a lot of stack space, so it's probably fine.

Added requested comment

From reading the thread on https://github.com/llvm/llvm-project/issues/16778 (which is closed, although the issue doesn't seem resolved), this is a stop-gap for toolchains that don't include an implementation for __muloti4. An implementation seems to exist in compiler-rt, but compiler-rt isn't linked with by default. It seems unfortunate that there is no way to still emit a call to __muloti4 when we do link with compiler-rt, but from reading that thread there is currently no way to tell LLVM that an implementation of __muloti4 is available.

Ping

The build failure on Debian is caused by a clangd unit test that seems unrelated to AArch64 codegen; I'm assuming for now that the failure isn't caused by this change.

Removed internal ticket identifiers from the commit message

Looks like I made a mistake in the test that causes the Windows build to fail (just received an email notification): infinite_recursion should be declared with return type void. Should I submit a new differential, or is there some way to fix this one?

In D101824#2739110, @morehouse wrote:

compiler-rt/test/fuzzer is better. Most tests there already build with ASan + libFuzzer.

Added a test and rephrased the commit message accordingly.

In D101824#2737042, @morehouse wrote:

Thanks for the fix. Could you add a test that fails before this fix and passes after it?