Stream: git-wasmtime

Topic: wasmtime / PR #14990 Don't use native signals on Unix tar...

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa opened PR #14990 from aofusa:fallback-unsupported-unix-signals to bytecodealliance:main:

On Unix targets where crates/wasmtime/src/runtime/vm/sys/unix/signals.rs has no code for reading and
updating the signal context, such as all NetBSD targets and OpenBSD/aarch64, building wasmtime fails
with compile_error!("unsupported platform").

This changes build.rs to only enable has_native_signals on Unix for the (OS, architecture) pairs
that signals.rs supports. Other Unix targets now build and behave like platforms without native
signals: signals-based traps are turned off, and compiled code performs explicit checks instead.
Nothing changes for targets that build today.

Changes:

• crates/wasmtime/build.rs: add has_unix_signal_handler, a list of the supported pairs, and use
  it when computing has_native_signals. Only architectures with a Cranelift backend are listed,
  since has_native_signals already requires one.

• signals.rs: comments next to the two compile_error!s pointing to the list in build.rs.

• CI: a cargo check job for x86_64-unknown-netbsd, next to the existing FreeBSD one.
• docs/stability-platform-support.md: a short note on this behavior.

Testing

• For all 331 targets from rustc --print target-list, I compared has_native_signals before and
  after this change, for each combination of the std and custom-native-signals features. It only
  changes from true to false on Unix targets with a Cranelift backend that signals.rs doesn't
  support (38 targets), and all of them fail to build without this change.

• macOS aarch64: cargo fmt --all -- --check, cargo clippy --workspace --all-targets --features p3,component-model-async with -Dwarnings, cargo test -p wasmtime.

• Linux aarch64 (VM): cargo test -p wasmtime with -Dwarnings.

• x86_64-unknown-netbsd, cross-checked from macOS, matching the new CI job: cargo check fails with
  unsupported platform without this change and passes with it, with -Dwarnings. Also
  cargo check -p wasmtime --no-default-features --features runtime,std,pulley.

• NetBSD 10.1 aarch64 (VM): cargo check -p wasmtime fails without this change and passes with it.
  cargo test -p wasmtime --lib passes (tests that JIT code need paxctl +m on the test binary,
  because of NetBSD's PaX MPROTECT). A small test program that checks traps (out-of-bounds memory
  access, division by zero, integer overflow, unreachable, bad float-to-int conversion,
  call_indirect to null, with the wrong signature and out of table bounds, stack overflow), fuel,
  epoch interruption, async with fuel yielding, and host function errors passes with both Cranelift
  native code and Pulley, with and without memory guard regions. The same program confirms that
  native signals are disabled at compile time on this target.

• OpenBSD 7.9 aarch64 (VM): main doesn't build with the packaged Rust 1.94 for unrelated reasons, so
  I applied the same build.rs change to Wasmtime 47.0.4 (MSRV 1.94). cargo check -p wasmtime
  fails with unsupported platform without the change and passes with it, and native signals are
  disabled at compile time. Running Wasm on OpenBSD/aarch64 still has separate issues that I didn't
  look into here: native code hits SIGILL at the first instruction of the compiled function, and
  synchronous Pulley calls crash in the interpreter. veil runs Wasm there with Pulley, async calls,
  and a custom stack creator that maps fiber stacks with MAP_STACK.

• veil, which vendors Wasmtime 36 with a similar patch: with
  the equivalent build.rs change applied to Wasmtime 36.0.19, veil's Proxy-Wasm end-to-end tests
  pass on NetBSD aarch64.

The NetBSD and OpenBSD VMs have Rust 1.96 and 1.94 from their package collections, which are older
than the MSRV, so I used --ignore-rust-version there. With these versions rustc also reports
unfulfilled #[expect(dead_code)] lints in cow.rs and sync_std.rs with
--no-default-features --features runtime,std,pulley; the same warnings appear with Rust 1.96 on
macOS without this change, so they're not related.

I didn't test running on NetBSD x86_64, only the cross check.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa requested cfallin for a review on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa removed the review request for wasmtime-core-reviewers from PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa requested wasmtime-core-reviewers for a review on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa removed the review request for wasmtime-default-reviewers from PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa requested wasmtime-default-reviewers for a review on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:31):

aofusa requested fitzgen for a review on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 10:34):

aofusa edited PR #14990:

Fixes #14991. See also #6962.

On Unix targets where crates/wasmtime/src/runtime/vm/sys/unix/signals.rs has no code for reading and
updating the signal context, such as all NetBSD targets and OpenBSD/aarch64, building wasmtime fails
with compile_error!("unsupported platform").

This changes build.rs to only enable has_native_signals on Unix for the (OS, architecture) pairs
that signals.rs supports. Other Unix targets now build and behave like platforms without native
signals: signals-based traps are turned off, and compiled code performs explicit checks instead.
Nothing changes for targets that build today.

Changes:

• crates/wasmtime/build.rs: add has_unix_signal_handler, a list of the supported pairs, and use
  it when computing has_native_signals. Only architectures with a Cranelift backend are listed,
  since has_native_signals already requires one.

• signals.rs: comments next to the two compile_error!s pointing to the list in build.rs.

• CI: a cargo check job for x86_64-unknown-netbsd, next to the existing FreeBSD one.
• docs/stability-platform-support.md: a short note on this behavior.

Testing

• For all 331 targets from rustc --print target-list, I compared has_native_signals before and
  after this change, for each combination of the std and custom-native-signals features. It only
  changes from true to false on Unix targets with a Cranelift backend that signals.rs doesn't
  support (38 targets), and all of them fail to build without this change.

• macOS aarch64: cargo fmt --all -- --check, cargo clippy --workspace --all-targets --features p3,component-model-async with -Dwarnings, cargo test -p wasmtime.

• Linux aarch64 (VM): cargo test -p wasmtime with -Dwarnings.

• x86_64-unknown-netbsd, cross-checked from macOS, matching the new CI job: cargo check fails with
  unsupported platform without this change and passes with it, with -Dwarnings. Also
  cargo check -p wasmtime --no-default-features --features runtime,std,pulley.

• NetBSD 10.1 aarch64 (VM): cargo check -p wasmtime fails without this change and passes with it.
  cargo test -p wasmtime --lib passes (tests that JIT code need paxctl +m on the test binary,
  because of NetBSD's PaX MPROTECT). A small test program that checks traps (out-of-bounds memory
  access, division by zero, integer overflow, unreachable, bad float-to-int conversion,
  call_indirect to null, with the wrong signature and out of table bounds, stack overflow), fuel,
  epoch interruption, async with fuel yielding, and host function errors passes with both Cranelift
  native code and Pulley, with and without memory guard regions. The same program confirms that
  native signals are disabled at compile time on this target.

• OpenBSD 7.9 aarch64 (VM): main doesn't build with the packaged Rust 1.94 for unrelated reasons, so
  I applied the same build.rs change to Wasmtime 47.0.4 (MSRV 1.94). cargo check -p wasmtime
  fails with unsupported platform without the change and passes with it, and native signals are
  disabled at compile time. Running Wasm on OpenBSD/aarch64 still has separate issues that I didn't
  look into here: native code hits SIGILL at the first instruction of the compiled function, and
  synchronous Pulley calls crash in the interpreter. veil runs Wasm there with Pulley, async calls,
  and a custom stack creator that maps fiber stacks with MAP_STACK.

• veil, which vendors Wasmtime 36 with a similar patch: with
  the equivalent build.rs change applied to Wasmtime 36.0.19, veil's Proxy-Wasm end-to-end tests
  pass on NetBSD aarch64.

The NetBSD and OpenBSD VMs have Rust 1.96 and 1.94 from their package collections, which are older
than the MSRV, so I used --ignore-rust-version there. With these versions rustc also reports
unfulfilled #[expect(dead_code)] lints in cow.rs and sync_std.rs with
--no-default-features --features runtime,std,pulley; the same warnings appear with Rust 1.96 on
macOS without this change, so they're not related.

I didn't test running on NetBSD x86_64, only the cross check.

Wasmtime GitHub notifications bot (Oct 26 2026 at 12:45):

aofusa edited PR #14990:

Fixes #14991. See also #6962.

On Unix targets where crates/wasmtime/src/runtime/vm/sys/unix/signals.rs has no code for reading and
updating the signal context, such as all NetBSD targets and OpenBSD/aarch64, building wasmtime fails
with compile_error!("unsupported platform").

This changes build.rs to only enable has_native_signals on Unix for the (OS, architecture) pairs
that signals.rs supports. Other Unix targets now build and behave like platforms without native
signals: signals-based traps are turned off, and compiled code performs explicit checks instead.
Nothing changes for targets that build today.

Changes:

• crates/wasmtime/build.rs: add has_unix_signal_handler, a list of the supported pairs, and use
  it when computing has_native_signals. Only architectures with a Cranelift backend are listed,
  since has_native_signals already requires one.

• CI: a cargo check job for x86_64-unknown-netbsd, next to the existing FreeBSD one.

• docs/stability-platform-support.md: a short note on this behavior.

Testing

• For all 331 targets from rustc --print target-list, I compared has_native_signals before and
  after this change, for each combination of the std and custom-native-signals features. It only
  changes from true to false on Unix targets with a Cranelift backend that signals.rs doesn't
  support (38 targets), and all of them fail to build without this change.

• macOS aarch64: cargo fmt --all -- --check, cargo clippy --workspace --all-targets --features p3,component-model-async with -Dwarnings, cargo test -p wasmtime.

• Linux aarch64 (VM): cargo test -p wasmtime with -Dwarnings.

• x86_64-unknown-netbsd, cross-checked from macOS, matching the new CI job: cargo check fails with
  unsupported platform without this change and passes with it, with -Dwarnings. Also
  cargo check -p wasmtime --no-default-features --features runtime,std,pulley.

• NetBSD 10.1 aarch64 (VM): cargo check -p wasmtime fails without this change and passes with it.
  cargo test -p wasmtime --lib passes (tests that JIT code need paxctl +m on the test binary,
  because of NetBSD's PaX MPROTECT). A small test program that checks traps (out-of-bounds memory
  access, division by zero, integer overflow, unreachable, bad float-to-int conversion,
  call_indirect to null, with the wrong signature and out of table bounds, stack overflow), fuel,
  epoch interruption, async with fuel yielding, and host function errors passes with both Cranelift
  native code and Pulley, with and without memory guard regions. The same program confirms that
  native signals are disabled at compile time on this target.

• OpenBSD 7.9 aarch64 (VM): main doesn't build with the packaged Rust 1.94 for unrelated reasons, so
  I applied the same build.rs change to Wasmtime 47.0.4 (MSRV 1.94). cargo check -p wasmtime
  fails with unsupported platform without the change and passes with it, and native signals are
  disabled at compile time. Running Wasm on OpenBSD/aarch64 still has separate issues that I didn't
  look into here: native code hits SIGILL at the first instruction of the compiled function, and
  synchronous Pulley calls crash in the interpreter. veil runs Wasm there with Pulley, async calls,
  and a custom stack creator that maps fiber stacks with MAP_STACK.

• veil, which vendors Wasmtime 36 with a similar patch: with
  the equivalent build.rs change applied to Wasmtime 36.0.19, veil's Proxy-Wasm end-to-end tests
  pass on NetBSD aarch64.

The NetBSD and OpenBSD VMs have Rust 1.96 and 1.94 from their package collections, which are older
than the MSRV, so I used --ignore-rust-version there. With these versions rustc also reports
unfulfilled #[expect(dead_code)] lints in cow.rs and sync_std.rs with
--no-default-features --features runtime,std,pulley; the same warnings appear with Rust 1.96 on
macOS without this change, so they're not related.

I didn't test running on NetBSD x86_64, only the cross check.

Wasmtime GitHub notifications bot (Oct 26 2026 at 15:13):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 26 2026 at 15:13):

alexcrichton added PR #14990 Don't use native signals on Unix targets without signal context support to the merge queue.

Wasmtime GitHub notifications bot (Oct 26 2026 at 15:37):

github-merge-queue[bot] removed PR #14990 Don't use native signals on Unix targets without signal context support from the merge queue.

Wasmtime GitHub notifications bot (Oct 26 2026 at 16:50):

github-actions[bot] added the label wasmtime:docs on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 16:50):

github-actions[bot] added the label wasmtime:api on PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 16:57):

cfallin commented on PR #14990:

Given that NetBSD and OpenBSD both do have POSIX signals and native signal context structs, wouldn't it be preferable to add the support for reading out the signal context?

(See #2980 where I did this for OpenBSD ~5 years ago; I bumped into the other issue you name, the MSRV lag, and ultimately didn't push it forward. But this particular missing bit isn't something we have to cut a corner on IMHO.)

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:02):

aofusa updated PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:04):

aofusa edited PR #14990:

Fixes #14991. See also #6962.

On Unix targets where crates/wasmtime/src/runtime/vm/sys/unix/signals.rs has no code for reading and
updating the signal context, such as all NetBSD targets and OpenBSD/aarch64, building wasmtime fails
with compile_error!("unsupported platform").

This changes build.rs to only enable has_native_signals on Unix for the (OS, architecture) pairs
that signals.rs supports. Other Unix targets now build and behave like platforms without native
signals: signals-based traps are turned off, and compiled code performs explicit checks instead.
Nothing changes for targets that build today.

Changes:

• crates/wasmtime/build.rs: add has_unix_signal_handler, a list of the supported pairs, and use
  it when computing has_native_signals. Only architectures with a Cranelift backend are listed,
  since has_native_signals already requires one.

• CI: a cross check job for x86_64-unknown-netbsd, next to the existing FreeBSD one (cross provides
  the C compiler that build scripts need, as for illumos).

• docs/stability-platform-support.md: a short note on this behavior.

Testing

• For all 331 targets from rustc --print target-list, I compared has_native_signals before and
  after this change, for each combination of the std and custom-native-signals features. It only
  changes from true to false on Unix targets with a Cranelift backend that signals.rs doesn't
  support (38 targets), and all of them fail to build without this change.

• macOS aarch64: cargo fmt --all -- --check, cargo clippy --workspace --all-targets --features p3,component-model-async with -Dwarnings, cargo test -p wasmtime.

• Linux aarch64 (VM): cargo test -p wasmtime with -Dwarnings.

• x86_64-unknown-netbsd, cross-checked from macOS, matching the new CI job: cargo check fails with
  unsupported platform without this change and passes with it, with -Dwarnings. Also
  cargo check -p wasmtime --no-default-features --features runtime,std,pulley.

• NetBSD 10.1 aarch64 (VM): cargo check -p wasmtime fails without this change and passes with it.
  cargo test -p wasmtime --lib passes (tests that JIT code need paxctl +m on the test binary,
  because of NetBSD's PaX MPROTECT). A small test program that checks traps (out-of-bounds memory
  access, division by zero, integer overflow, unreachable, bad float-to-int conversion,
  call_indirect to null, with the wrong signature and out of table bounds, stack overflow), fuel,
  epoch interruption, async with fuel yielding, and host function errors passes with both Cranelift
  native code and Pulley, with and without memory guard regions. The same program confirms that
  native signals are disabled at compile time on this target.

• OpenBSD 7.9 aarch64 (VM): main doesn't build with the packaged Rust 1.94 for unrelated reasons, so
  I applied the same build.rs change to Wasmtime 47.0.4 (MSRV 1.94). cargo check -p wasmtime
  fails with unsupported platform without the change and passes with it, and native signals are
  disabled at compile time. Running Wasm on OpenBSD/aarch64 still has separate issues that I didn't
  look into here: native code hits SIGILL at the first instruction of the compiled function, and
  synchronous Pulley calls crash in the interpreter. veil runs Wasm there with Pulley, async calls,
  and a custom stack creator that maps fiber stacks with MAP_STACK.

• veil, which vendors Wasmtime 36 with a similar patch: with
  the equivalent build.rs change applied to Wasmtime 36.0.19, veil's Proxy-Wasm end-to-end tests
  pass on NetBSD aarch64.

The NetBSD and OpenBSD VMs have Rust 1.96 and 1.94 from their package collections, which are older
than the MSRV, so I used --ignore-rust-version there. With these versions rustc also reports
unfulfilled #[expect(dead_code)] lints in cow.rs and sync_std.rs with
--no-default-features --features runtime,std,pulley; the same warnings appear with Rust 1.96 on
macOS without this change, so they're not related.

I didn't test running on NetBSD x86_64, only the cross check.

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:09):

aofusa commented on PR #14990:

Given that NetBSD and OpenBSD both do have POSIX signals and native signal context structs, wouldn't it be preferable to add the support for reading out the signal context?

(See #2980 where I did this for OpenBSD ~5 years ago; I bumped into the other issue you name, the MSRV lag, and ultimately didn't push it forward. But this _particular_ missing bit isn't something we have to cut a corner on IMHO.)

Agreed that reading out the signal context would be the better fix for NetBSD and OpenBSD, and
thanks for the pointer to #2980. I don't plan to work on that myself, though, so I kept this PR to
the build fallback:

• It also covers the other Unix targets with a Cranelift backend that signals.rs doesn't support
  yet, so they build instead of hitting compile_error!.

• It doesn't get in the way of adding the signal context support later: once a platform is added to
  signals.rs and to the list in build.rs, it uses native signals again.

• On OpenBSD/aarch64, native code currently crashes for other reasons (SIGILL at the first
  instruction of the compiled function), so I can't validate signal handling there yet.

#6962 can stay open to track the signal context support.

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:11):

aofusa edited PR #14990:

Fixes #14991. See also #6962.

On Unix targets where crates/wasmtime/src/runtime/vm/sys/unix/signals.rs has no code for reading and
updating the signal context, such as all NetBSD targets and OpenBSD/aarch64, building wasmtime fails
with compile_error!("unsupported platform").

This changes build.rs to only enable has_native_signals on Unix for the (OS, architecture) pairs
that signals.rs supports. Other Unix targets now build and behave like platforms without native
signals: signals-based traps are turned off, and compiled code performs explicit checks instead.
Nothing changes for targets that build today.

Changes:

• crates/wasmtime/build.rs: add has_unix_signal_handler, a list of the supported pairs, and use
  it when computing has_native_signals. Only architectures with a Cranelift backend are listed,
  since has_native_signals already requires one.

• CI: a cross check job for x86_64-unknown-netbsd, next to the existing FreeBSD one (cross provides
  the C compiler that build scripts need, as for illumos).

• docs/stability-platform-support.md: a short note on this behavior.

Testing

• For all 331 targets from rustc --print target-list, I compared has_native_signals before and
  after this change, for each combination of the std and custom-native-signals features. It only
  changes from true to false on Unix targets with a Cranelift backend that signals.rs doesn't
  support (38 targets), and all of them fail to build without this change.

• macOS aarch64: cargo fmt --all -- --check, cargo clippy --workspace --all-targets --features p3,component-model-async with -Dwarnings, cargo test -p wasmtime.

• Linux aarch64 (VM): cargo test -p wasmtime with -Dwarnings.

• x86_64-unknown-netbsd, cross-checked from macOS, with clang and a NetBSD sysroot: cargo check fails with
  unsupported platform without this change and passes with it, with -Dwarnings. Also
  cargo check -p wasmtime --no-default-features --features runtime,std,pulley.

• NetBSD 10.1 aarch64 (VM): cargo check -p wasmtime fails without this change and passes with it.
  cargo test -p wasmtime --lib passes (tests that JIT code need paxctl +m on the test binary,
  because of NetBSD's PaX MPROTECT). A small test program that checks traps (out-of-bounds memory
  access, division by zero, integer overflow, unreachable, bad float-to-int conversion,
  call_indirect to null, with the wrong signature and out of table bounds, stack overflow), fuel,
  epoch interruption, async with fuel yielding, and host function errors passes with both Cranelift
  native code and Pulley, with and without memory guard regions. The same program confirms that
  native signals are disabled at compile time on this target.

• OpenBSD 7.9 aarch64 (VM): main doesn't build with the packaged Rust 1.94 for unrelated reasons, so
  I applied the same build.rs change to Wasmtime 47.0.4 (MSRV 1.94). cargo check -p wasmtime
  fails with unsupported platform without the change and passes with it, and native signals are
  disabled at compile time. Running Wasm on OpenBSD/aarch64 still has separate issues that I didn't
  look into here: native code hits SIGILL at the first instruction of the compiled function, and
  synchronous Pulley calls crash in the interpreter. veil runs Wasm there with Pulley, async calls,
  and a custom stack creator that maps fiber stacks with MAP_STACK.

• veil, which vendors Wasmtime 36 with a similar patch: with
  the equivalent build.rs change applied to Wasmtime 36.0.19, veil's Proxy-Wasm end-to-end tests
  pass on NetBSD aarch64.

The NetBSD and OpenBSD VMs have Rust 1.96 and 1.94 from their package collections, which are older
than the MSRV, so I used --ignore-rust-version there. With these versions rustc also reports
unfulfilled #[expect(dead_code)] lints in cow.rs and sync_std.rs with
--no-default-features --features runtime,std,pulley; the same warnings appear with Rust 1.96 on
macOS without this change, so they're not related.

I didn't test running on NetBSD x86_64, only the cross check.

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:22):

aofusa commented on PR #14990:

The NetBSD platform check failed in the merge queue because the runner has no C compiler for
NetBSD (needed by capstone-sys). I switched it to cross, as for illumos, and it now passes
with `prtest:platform-checks

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:28):

aofusa edited a comment on PR #14990:

The NetBSD platform check failed in the merge queue because the runner has no C compiler for
NetBSD (needed by capstone-sys). I switched it to cross, as for illumos, and it now passes
with prtest:platform-checks.

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:30):

aofusa edited a comment on PR #14990:

Given that NetBSD and OpenBSD both do have POSIX signals and native signal context structs, wouldn't it be preferable to add the support for reading out the signal context?

(See #2980 where I did this for OpenBSD ~5 years ago; I bumped into the other issue you name, the MSRV lag, and ultimately didn't push it forward. But this _particular_ missing bit isn't something we have to cut a corner on IMHO.)

Agreed that reading out the signal context would be the better fix for NetBSD and OpenBSD, and
thanks for the pointer to #2980. I don't plan to work on that myself, though, so I kept this PR to
the build fallback:

• It also covers the other Unix targets with a Cranelift backend that signals.rs doesn't support
  yet, so they build instead of hitting compile_error!.

• It doesn't get in the way of adding the signal context support later: once a platform is added to
  signals.rs and to the list in build.rs, it uses native signals again.

• On OpenBSD/aarch64, native code currently crashes for other reasons (SIGILL at the first
  instruction of the compiled function), so I can't validate signal handling there yet.

Thanks for taking a look

Wasmtime GitHub notifications bot (Oct 26 2026 at 19:32):

aofusa edited a comment on PR #14990:

Given that NetBSD and OpenBSD both do have POSIX signals and native signal context structs, wouldn't it be preferable to add the support for reading out the signal context?

(See #2980 where I did this for OpenBSD ~5 years ago; I bumped into the other issue you name, the MSRV lag, and ultimately didn't push it forward. But this _particular_ missing bit isn't something we have to cut a corner on IMHO.)

Agreed that reading out the signal context would be the better fix for NetBSD and OpenBSD, and
thanks for the pointer to #2980. I don't plan to work on that myself, though, so I kept this PR to
the build fallback:

• It also covers the other Unix targets with a Cranelift backend that signals.rs doesn't support
  yet, so they build instead of hitting compile_error!.

• It doesn't get in the way of adding the signal context support later: once a platform is added to
  signals.rs and to the list in build.rs, it uses native signals again.

• On OpenBSD/aarch64, native code currently crashes for other reasons (SIGILL at the first
  instruction of the compiled function), so I can't validate signal handling there yet.

Thanks for taking a look.

Wasmtime GitHub notifications bot (Oct 26 2026 at 22:14):

alexcrichton commented on PR #14990:

My thinking is that while I agree implementing and filling this out is best we should also strive to compile on all platforms by default with Pulley support. My hope is that if Wasmtime ends up getting used more on these platforms then someone will be sufficiently motivated to fix the perf, but being able to get in the door at all still seems valuable.

Wasmtime GitHub notifications bot (Oct 26 2026 at 22:14):

alexcrichton added PR #14990 Don't use native signals on Unix targets without signal context support to the merge queue.

Wasmtime GitHub notifications bot (Oct 26 2026 at 22:47):

:check: alexcrichton merged PR #14990.

Wasmtime GitHub notifications bot (Oct 26 2026 at 22:47):

alexcrichton removed PR #14990 Don't use native signals on Unix targets without signal context support from the merge queue.

Last updated: Oct 31 2026 at 23:03 UTC