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.
- All Stories
- Advanced Search
- Transaction Logs
Wed, May 10
Jan 24 2023
Added requested comment
Jan 23 2023
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.
Jan 22 2023
Jan 16 2023
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
May 7 2021
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.
May 5 2021
In D101824#2737042, @morehouse wrote:
Thanks for the fix. Could you add a test that fails before this fix and passes after it?