Add a wasm32-wasip3 target

[alexcrichton]

Almost all functions are stubbed out to return errors. This is all done
in preparation for eventually filling out these functions, but the goal
of this commit is to lay down the scaffolding of the target rather than
actually implement anything.

CI jobs are added to build and test this target. Most tests are expected
to fail, but all tests are still run as usual. Once tests are passing
they'll be updated in CMakeLists.txt to flag the test as expected to
pass instead of expected to fail.

This is a very large PR line-wise, but all the major changes with large
chunks of code are generated code and are expected to be easy to review.
The actual changes here in the source are primarily:

• Adding #elif defined(__wasip3__) cases
• Sometimes using the WASIp2 definitions of functions for WASIp3
• Shuffling naming in the network utilities to support both WASIp2 and
  WASIp3 which have the same types, just renamed.
• Generated bindings for WASIp3 are now vendored like WASIp2 bindings.
• Wasmtime is updated for testing to be able to run generated WASIp3
  binaries.

[alexcrichton]

Procedurally, I wanted to open this to showcase my thoughts on what wasm32-wasip3 will look like. This isn't ready for usage (everything, including printing, returns an error and is unimplemented) nor distribution. What it is ready for, however, would be to incrementally land implementations of functions after this PR.

This is split up into a number of commits that I plan to land as separate PRs. For example:

• ec14bef - this is Sever wasip2's dependence on wasip1 headers #694
• 487f158 - this refactors __wasilibc_use_wasip2 into __wasip{1,2,3}__ depending on the target
• d782d51 - this shuffles code ifdef'd for wasip1/wasip2 to make it easier to slot in wasip3
• 2497060 - this is the actual new target. The lion's share of raw lines changed are related to generated files

[cpetig]

I have a first working stdout implementation for p3 based on this patch at https://github.com/cpetig/wasi-libc/tree/wasip3 .

I guess that p3 needs some more infrastructure (exports_wasi_cli_run_result_void_void_t, exports_wasi_cli_run_run_return, ...) to define wasi:cli/run.run (added in my patch) but this should become a separate object file from wasip3.o to enable reactor type binaries. (In Rust I would use --with to separate the non cli-run parts in wit-bindgen, I think C doesn't have this functionality, yet)

[cpetig]

PS:
I can separate the stdout implementation (non-controversial) from run whenever you feel this would be helpful.

[cpetig]

See also alexcrichton#1

[alexcrichton]

Thanks! My plan was to land implementation work of actual interfaces as separate PRs to make them easier to review so I'm going to hold off on merging that into this PR's branch, but @cpetig would you be willing to do a follow-up once this PR lands? I'd be happy to review!

[cpetig]

Thanks! My plan was to land implementation work of actual interfaces as separate PRs to make them easier to review so I'm going to hold off on merging that into this PR's branch, but @cpetig would you be willing to do a follow-up once this PR lands? I'd be happy to review!

😉 My plan with alexcrichton#1 was to show that there is benefit in getting this PR merged even in its incomplete state.

I will rebase the patches and move discussion to https://github.com/WebAssembly/wasi-libc/pulls once this PR is merged.

[alexcrichton]

Ok all the requisite pieces have now landed so this should be good to go

[TartanLlama]

Why __generated_wasip2.h but not __generate_wasip3.h?

[cpetig]

because there is a wasm32-wasip3/include-all.c which contains __generate_wasip3.h, I guess.

[alexcrichton]

Oh this is due to how include-all.c works. The file is generated here during the check-symbols step and is a #include of all headers located in the sysroot. The sysroot differs from wasip2 to wasip3 due to this cmake logic

The general idea was that I didn't want to tamper with the auto-generated output of wit-bindgen too too much (doing the seds below is already cumbersome enough). I also didn't want header files to be available in a wasip2 sysroot, for example to give access to wasip3 APIs. For example #include <wasi/wasip3.h> expands to nothing on wasm32-wasip2, intentionally so.

[TartanLlama]

I don't see a p3 version of exports_wasi_cli_run_run, is that intentional? Trying to run through wasmtime at the moment falls back to wasi:cli/[email protected]#run for me. Does that come from wasm-tools?

[cpetig]

I don't see a p3 version of exports_wasi_cli_run_run, is that intentional? Trying to run through wasmtime at the moment falls back to wasi:cli/[email protected]#run for me. Does that come from wasm-tools?

There is a rework of wasi:cli/run support in progress at #710 and independently my older implementation in alexcrichton#1 adds it in https://github.com/alexcrichton/wasi-libc/pull/1/files#diff-45b136af96af6bbdf678da48be957d098c7f1cd55981e05e3fa92635b70501a5R113 . I am waiting for these two independent patches to land to rework my patch.

PS: I have some trouble compiling libc++ with your wasip3 llvm version ([l]ldiv[_t] missing in cstdlib), I am not sure whether I fumbled some pre-existing local temporary files or mixed the wrong flavor of sdk+llvm+libc . Still working to gather more details on which combination works (not).

[TartanLlama]

There is a rework of wasi:cli/run support in progress at #710 and independently my older implementation in alexcrichton#1 adds it in https://github.com/alexcrichton/wasi-libc/pull/1/files#diff-45b136af96af6bbdf678da48be957d098c7f1cd55981e05e3fa92635b70501a5R113 . I am waiting for these two independent patches to land to rework my patch.

Ah, cool, that will likely simplify things for P3 as well as I can make wasm-tools inject code to setup the stack pointer and TLS base rather than having to have an asm entry point for libc.

PS: I have some trouble compiling libc++ with your wasip3 llvm version ([l]ldiv[_t] missing in cstdlib), I am not sure whether I fumbled some pre-existing local temporary files or mixed the wrong flavor of sdk+llvm+libc . Still working to gather more details on which combination works (not).

I haven't tried compiling libc++ with it yet. Sounds like maybe missing compiler-rt?

[cpetig]

because there is a wasm32-wasip3/include-all.c which contains __generate_wasip3.h, I guess.

[cpetig]

My question would be more: Why include wasip1.h and wasip3.h in wasm32-wasip2/include-all.c?

[alexcrichton]

Good point! I sort of arbitrarily decided that I ideally want header files to be present on all targets, but the contents will differ per-target. I don't have the strongest of reasons for doing so, but this means that all these headers are present on all targets, but #ifdef and such means that on any one target only one of these headers actually expands to anything.

[alexcrichton]

For exports_wasi_cli_run_run @cpetig is correct yeah. I didn't really try too too hard to get tests working or anything like that on wasm32-wasip3, it's mostly just building. I think we'll definitely need to copy over some logic from #710 for wasip3 (shouldn't be too too hard)

@cpetig FWIW the change you have of using wasi:cli/command instead of wasi:cli/imports was undone in #641, so we can't in general use wasi:cli/command for the generated bindings libc uses.

PS: I have some trouble compiling libc++ with your wasip3 llvm version ([l]ldiv[_t] missing in cstdlib)

oh dear! If you've got an error message and/or test case I can try to dig in too

Ah, cool, that will likely simplify things for P3 as well as I can make wasm-tools inject code to setup the stack pointer and TLS base rather than having to have an asm entry point for libc.

Agreed!

[cpetig]

oh dear! If you've got an error message and/or test case I can try to dig in too

This was caused by an outdated system wide WASI.cmake which set sysroot (last resort solution I went for some weeks ago). Then I tried combining Sy's llvm patch with your patch to enable cmake on libc and my and all our available wasip3 patches on libc.

This went sort of well (I had to define_compiler_rt(wasm32-wasip3) and patch wasi-sdk-sysroot.cmake to use it (add_custom_target) - because of the binary incompatibility all binaries (udiv etc.) compiled for wasip1 will cause a linker failure, so you easily spot mistakes. Then I hit a missing __exception_unwind (loosely remembered symbol) and turned on exceptions for the build.

Now I am down to

.../wasi-sdk/build/sysroot/libcxx-wasm32-wasip3-lto-build-prefix/src/libcxx-wasm32-wasip3-lto-build-build/include/c++/v1/__functional/hash.h:40:8: error: reference to unresolved using declaration
   40 |   std::memcpy(std::addressof(__r), __p, sizeof(__r));
      |        ^
.../wasi-sdk/build/sysroot/libcxx-wasm32-wasip3-lto-build-prefix/src/libcxx-wasm32-wasip3-lto-build-build/include/c++/v1/cstring:82:1: note: using declaration annotated with 'using_if_exists' here
   82 | using ::memcpy _LIBCPP_USING_IF_EXISTS;

which shows me how complicated the situation with (builtin_) memcpy is. But it looks that it might take effort but can moderately easy solved. ⌛

[alexcrichton]

@cpetig ah ok makes sense, given that I think I'll go ahead and merge this so we can start incrementally merging things and moving towards making that more reproducible, for example, in a PR with some changes to help narrow it down.