Stream: git-wasmtime

Topic: wasmtime / PR #10107 Improve support for completely unkno...

Wasmtime GitHub notifications bot (Jan 24 2025 at 21:17):

alexcrichton opened PR #10107 from alexcrichton:support-unknown-architecture to bytecodealliance:main:

This commit is a step in the direction of trying to make Wasmtime more portable by default. The goal here is to enable Wasmtime to compile for architectures that it has no prior knowledge of. There's a few miscellaneous locations through Wasmtime where we need architecture-specific intrinsics and such but that's all in service of Cranelift itself. Without Cranelift support none of them are necessary.

This commit plumbs a custom #[cfg] from Wasmtime's build.rs script into the crate about whether there's a supported Cranelift backend. If this isn't available some architecture-specific intrinsics are turned off and not included. An example is that vm::arch entirely disappears which is only in service of UnwindHost, which also disappears. Furthermore the helpers.c file also entirely disappears as it's not necessary on unknown architectures.

To help keep this working I've added CI to build Wasmtime for powerpc64le-unknown-linux-gnu. Wasmtime currently has no support for this architecture, although if it grows such support in the future this'll need to be changed to some other unsupported architecture.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jan 24 2025 at 21:17):

alexcrichton requested wasmtime-core-reviewers for a review on PR #10107.

Wasmtime GitHub notifications bot (Jan 24 2025 at 21:17):

alexcrichton requested fitzgen for a review on PR #10107.

Wasmtime GitHub notifications bot (Jan 24 2025 at 21:17):

alexcrichton requested wasmtime-default-reviewers for a review on PR #10107.

Wasmtime GitHub notifications bot (Jan 24 2025 at 22:58):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Jan 24 2025 at 22:58):

fitzgen created PR review comment:

Can we rename this has_host_compiler_backend? While we don't have any target supported on Winch but not Cranelift now, it doesn't seem like it would be impossible in the future, so we should just try to be a little more precise about what we are saying.

Wasmtime GitHub notifications bot (Jan 27 2025 at 17:55):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 17:55):

alexcrichton has enabled auto merge for PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 18:27):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 18:27):

alexcrichton has enabled auto merge for PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 19:05):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 19:05):

alexcrichton has enabled auto merge for PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 21:16):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 22:01):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 23:44):

github-actions[bot] commented on PR #10107:

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• [ ] If you added a new Config method, you wrote extensive documentation for
  it.

  <details>

  Our documentation should be of the following form:

  ```text
  Short, simple summary sentence.

  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.

  Is this method fallible? If so, when can it return an error?

  Can this method panic? If so, when does it panic?

  Example

  Optional example here.
  ```

  </details>

• [ ] If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  <details>

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See [our docs on fuzzing][fuzzing-docs] for more details.

  </details>

• [ ] If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

---

<details>

To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.

To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.

Learn more.

</details>

Wasmtime GitHub notifications bot (Jan 27 2025 at 23:46):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 27 2025 at 23:51):

alexcrichton commented on PR #10107:

I probably should have done prtest:full sooner but as can probably be seen there's a lot of fixup commits here to get tests passing on all platforms in CI and such. Nontrivial changes include:

• Validation of Tunables for execution at runtime is deferred until a module is loaded. This enables 32-bit platforms, which disable signals_based_traps, to compile for 64-bit platforms (e.g. the disas test suite)
• Auto-configuration of Tunables based on crate features is skipped if --target is passed. This fixes disas cross-compilation tests from 32-to-64-bit where 64-bit hosts expect signals-based-traps.
• Some standalone tests/*.rs files have moved from /tests/*.rs to /crates/wasmtime/tests/*.rs to be able to use the #[cfg] directives printed by crates/wasmtime/build.rs
• Default Tunables for Pulley targets have been auto-adjusted to assume no signals-based-traps and no memory reservation. This fixes --target pulley32 on 32-bit platforms where the second bullet above wasn't otherwise applying to auto-disable from the defaults.
• Stack overflow messages for overflowing the async stack no longer happen with Pulley. That's because we no longer (intentionally) install signal handlers.

Juggling compile options I feel still isn't great. Ideally everything "just works" but it's a narrow needle to thread trying to juggle different crate features and targetting different environments. Ideally we'd be able to query has_native_signals and has_virtual_memory based on target_lexicon::Triple, but that involves inferring cfg(unix) or cfg(windows) which is a bit of a stretch at this time. I've attempted to have at least a somewhat reasonable middle-ground in the meantime.

Wasmtime GitHub notifications bot (Jan 28 2025 at 00:45):

alexcrichton updated PR #10107.

Wasmtime GitHub notifications bot (Jan 28 2025 at 01:26):

alexcrichton merged PR #10107.

Last updated: Feb 28 2025 at 03:10 UTC