exports for wasi_snapshot_preview1::fd_write in memory64 has 32 bit pointers

[yowl]

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

Wasm file uploaded

Steps to Reproduce

Run with wasmtime --wasm-features memory64

Expected Results

It runs

Actual Results

Fails with

Error: failed to run main module `C:\Users\ScottWaye\OneDrive\wasm64\1.wasm`

Caused by:
    0: failed to instantiate "C:\\Users\\ScottWaye\\OneDrive\\wasm64\\1.wasm"
    1: incompatible import type for `wasi_snapshot_preview1::fd_write`
    2: function types incompatible: expected func of type `(i32, i64, i64, i64) -> (i32)`, found func of type `(i32, i32, i32, i32) -> (i32)`

Versions and Environment

Wasmtime version or commit: wasmtime 0.31.0

Operating system: Win10

Architecture: x64?

Extra Info

Looks like the wasi export is using 32 bit pointers when for memory64 shouldn't it be 64 bit?

Anything else you'd like to add?
1.zip

[yowl]

The error message is not clear and it could be that wasmtime is right and my import is wrong. Unfortuantely wabt's wasm2wat doesn't work for memory64 so not sure how to check that.

[alexcrichton]

The support for memory64 is not complete and it's still experimental, this is one of the reasons why. Our WASI support currently does not work on memory64, not because it's a fundamental issue but rather because it's just not supported yet, it's something we need to implement and design.

[yowl]

Thanks, its not a big deal for me. I was just looking for a way to test my own 64 support!

[yagehu]

@alexcrichton I hacked together wasm64-wasip1 support for my research needs: https://github.com/yagehu/wasmtime

Currently, it largely duplicates wasmtime-wasi's p1.rs module, so it's not ideal. I attempted a more elegant solution by parameterizing the memory size in wiggle's generated types but stopped because that requires intrusive changes to wasi-common, wiggle, and wasmtime-wasi.

Does the team have any interest in upstreaming this ABI along with the wasi-libc changes? People have expressed interest (e.g. WebAssembly/wasi-sdk#212).

[pchickey]

We will not be upstreaming anything into wasmtime that is not standards-compliant. Adding a 64-bit memory ABI to wasip1 will have to be approved by the WASI subgroup before adding it to wasmtime, and in prior discussions in the WASI subgroup there were numerous strong objections to adding wasm64 to wasip1, because wasip1 is already subsumed by the wasip2 (and soon wasip3) revisions.

The last time this came up the action items to move forward in the standards and wasmtime were to add 64-bit memory support to the component model spec, then to wasmtime's component model implementation: #4311 WebAssembly/component-model#22 . These action items still need someone to work on them.

[yagehu]

That's totally reasonable. Thanks for the context.