Stream: git-wasmtime

Topic: wasmtime / issue #3899 Implement runtime checks for compi...

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 19:56):

alexcrichton commented on issue #3899:

This actually ended up catching a preexisting bug in our spectests implementation during cargo test where reference types are enabled but by calling Config::strategy it overwrites the compiler builder meaning existing settings are removed (such as enable_safepoints) and later when a module is instantiated reference types are enabled but safepoints aren't. Previously this was allowed but now it's rejected at Module-creation time. For now the fix I implemented was to avoid calling Config::strategy, but now that I say this out loud it might be better to simply remove the Config::strategy method since it doesn't do anything anyway and is sort of dangerous to blow away existing settings.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 08 2022 at 20:06):

github-actions[bot] commented on issue #3899:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 12:20):

uweigand commented on issue #3899:

I just noticed that this seems to have broken the test suite on IBM Z when running on z15 or later. All wasi_tokio tests now fail with:

    0: compilation settings are not compatible with the native host
    1: cannot test if target-specific flag "has_mie2" is available at runtime

It looks like the JIT auto-detects the availability of the MIE2 feature (from cranelift-native), but then wasmtime checks again but now thinks that feature is unsupported (since there is no IBM Z support in check_compatible_with_isa_flag yet).

What's the right approach here? Just re-implement the feature check? (I must admit I'm not sure what the point of the double checking here is, in particular with a duplicated code base ...)

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 14:33):

alexcrichton commented on issue #3899:

Yeah in this case implementing the check is good. The purpose of this is to guard against loading precompiled modules with the wrong configuration settings. The duplication is unfortunate but I didn't see any obvious way to unify things (one says "activate the right features for the host" and the other says "verify each feature against the host", different enough I couldn't figure out how to abstract).

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 15:07):

uweigand commented on issue #3899:

OK, I've now implemented this here: https://github.com/bytecodealliance/wasmtime/pull/4101

Last updated: Nov 22 2024 at 17:03 UTC