Stream: git-wasmtime

Topic: wasmtime / issue #3594 exports for wasi_snapshot_preview1...


view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2021 at 15:15):

yowl labeled issue #3594:

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2021 at 15:15):

yowl opened issue #3594:

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2021 at 15:21):

yowl commented on issue #3594:

To be honest 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.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 09 2021 at 15:22):

yowl edited a comment on issue #3594:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 13 2021 at 15:25):

alexcrichton commented on issue #3594:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 13 2021 at 15:29):

yowl commented on issue #3594:

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 13 2021 at 15:33):

alexcrichton unlabeled issue #3594:

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 13 2021 at 15:33):

alexcrichton labeled issue #3594:

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

view this post on Zulip Wasmtime GitHub notifications bot (Dec 01 2025 at 22:01):

yagehu commented on issue #3594:

@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. https://github.com/WebAssembly/wasi-sdk/issues/212).

view this post on Zulip Wasmtime GitHub notifications bot (Dec 01 2025 at 22:27):

pchickey commented on issue #3594:

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: https://github.com/bytecodealliance/wasmtime/issues/4311 https://github.com/WebAssembly/component-model/issues/22 . These action items are still looking for someone to work on them

view this post on Zulip Wasmtime GitHub notifications bot (Dec 01 2025 at 22:27):

pchickey edited a comment on issue #3594:

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: https://github.com/bytecodealliance/wasmtime/issues/4311 https://github.com/WebAssembly/component-model/issues/22 . These action items still need someone to work on them.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 02 2025 at 20:16):

yagehu commented on issue #3594:

That's totally reasonable. Thanks for the context.


Last updated: Dec 13 2025 at 21:03 UTC