Support wasm64

[trcrsired]

I need to make changes to the "c_header.rs" file because there are numerous instances where "size_t" is mistakenly identified as "uint32_t," which is incompatible with wasm64.

[trcrsired]

@yamt Hello. Can you start the CI for me? Thank you

[yamt]

@yamt Hello. Can you start the CI for me? Thank you

i have no special permissions on this repo. @abrown ping

[trcrsired]

@abrown Hi. Could you explain why CI is not automatic but needs action from the maintainers?

[trcrsired]

I have removed all signal apis from the upstream file and regenerated api.h and __wasi_realfile.c.

[trcrsired]

Add CI for wasm64-wasi + wasm64-wasi-threads Add noexcept to all apis.

[sunfishcode]

This PR would effectively create a new wasm64 preview1 ABI, as well as a new wasi-threads ABI. Those are major new interfaces, that could eventually impact a large number of tools and engines. Since this is an official WebAssembly organization project, we should discuss this in a WASI Subgroup meeting before proceeding with this PR.

[trcrsired]

This PR would effectively create a new wasm64 preview1 ABI, as well as a new wasi-threads ABI. Those are major new interfaces, that could eventually impact a large number of tools and engines. Since this is an official WebAssembly organization project, we should discuss this in a WASI Subgroup meeting before proceeding with this PR.

i am thinking of duplicate apis instead of just making the 32 and 64 the same. Duplicating apis are much easier for virtual machine to implement and leaving more flexibility for programmers and not breaking existing tools.

Like __wasi_preview1_fd_write can have its __wasi_preview1_fd_write_i64 version which accepts i64 as its pointer.

[trcrsired]

This works now.

[sunfishcode]

i am thinking of duplicate apis instead of just making the 32 and 64 the same. Duplicating apis are much easier for virtual machine to implement and leaving more flexibility for programmers and not breaking existing tools.

Like __wasi_preview1_fd_write can have its __wasi_preview1_fd_write_i64 version which accepts i64 as its pointer.

Even so, it's still a major expansion in the WASI preview1 surface area, so we should get Subgroup guidance before this could be merged.

[trcrsired]

changed to _wasm64 based on feedback

[TianlongLiang]

Hi, I tried your awesome wasm64 support patch with some wasi-threads samples, and have the following result:

wasm-ld: error: Global type mismatch: __stack_pointer
>>> defined as var i64 in <internal>
>>> defined as var i32 in /opt/wasi-sdk/build/wasi-sdk-21.4ga1b80857c490+m/bin/../share/wasi-sysroot/lib/wasm64-wasi-threads/libc.a(__init_tls.o)

It seems that this line of code in this directory also needs to be modified(i64 when it's wasm64). After I modify it and recompile it, it gets rid of the linking error. What do you think?

[loganek]

@trcrsired what's the status of the work? I seriously consider using wasm64 in one of my projects as that'd solve a few problems; if the work is abandoned, I'm happy to pick it up and drive further (i.e. discuss with WASI subgroup, finalize the PR).

[loganek]

Since there wasn't any progress on that PR for the last 1.5 month, I'm planning to close on the discussion and finalize the PR. I've requested a slot in the next WASI SG meeting; hopefully we can discuss all the concerns and agree on the next steps: https://github.com/WebAssembly/meetings/pull/1479