Stream: general

Topic: Dealing with missing imports

Alexandru Ene (Jan 28 2021 at 11:55):

Hello,

Right now it is not permitted to have missing imports in a wasm module as it's considered corrupted and it will not execute. This means that for situations that for the scenario where you have in the wild various versions of a WASM host that exposes functions to be used by a binary, you need to create separate WASM files for each version that's out there.

Things like this aren't possible right now:

if (vm_host_has_feature("feature_name") {
     call_function_from_vm_because_it_should_exist_here();
} else {
     fallback_bhv();
}

Given this scenario is semi common (e.g. someone may want mods built for new versions of the game to work on the old version too. It's not really a good developer experience for people to maintain pipelines that output X binary versions that are guarded by #[feature] flags and it would be nice to allow imports to be missing.

The behavior for when you call a missing imported function is that you get a trap.

I have a couple of questions:
1) Why is the standard not allowing my proposed behavior? What's the reason to ask for all imports to be there?
2) Could we have a build option / feature flag on WASMTIME to allow for this?

Thanks,
Alex

Till Schneidereit (Jan 28 2021 at 12:08):

Hey @Alexandru Ene, this came up in a recent issue, too: https://github.com/bytecodealliance/wasmtime/issues/2587

The tl;dr is that we want to avoid a proliferation of non-standard interfaces that might tie the hands of the WASI standardization effort later on. However, I agree that there's a real need to satisfy here, too. Do you think my suggestion in that thread would be a viable solution for you? And if so, would you be up for adding support for such a flag?

Alexandru Ene (Jan 28 2021 at 12:10):

If that permits imports that aren't found to be replaced by a trap if called, allowing the module to run it is a great solution! Thanks :grinning:

I can start work to add it on my side.

What would be the best way to propose this change to the WASM standard to relax that requirement on imports?

Till Schneidereit (Jan 28 2021 at 12:20):

I can start work to add it on my side.

Great!

What would be the best way to propose this change to the WASM standard to relax that requirement on imports?

Hmm, good question. I'm not sure where it best fits in, but perhaps the WASI subgroup might be the right place? @Dan Gohman and @Lin Clark, what's your take on this?

Dan Gohman (Jan 28 2021 at 18:42):

Yes, the WASI Subgroup has a design for Optional Imports which does this.

Alexandru Ene (Feb 04 2021 at 13:37):

Thanks both, I've raised this PR: https://github.com/bytecodealliance/wasmtime/pull/2637

Last updated: Oct 23 2024 at 20:03 UTC