Update a few aspects of the adapter build

[alexcrichton]

• Use the wasm32-unknown-unknown target for the adapter and specify flags in .cargo/config.toml to avoid having to pass the same flags everywhere. This allows using wasm32-wasi for tests to ensure the flags only apply to the adapter.

• Use opt-level=s since speed is not of the utmost concern for this wasm but since it's likely to be included in many places size is likely more important.

• Use strip = 'debuginfo' for the release build to remove the standard library's debugging information which isn't necessary.

• Remove debug = 0 from the dev profile to have debugging information for development.

• Add a small README.md describing what's here for now.

[sunfishcode]

One unfortunate thing about wasm32-unknown-unknown is that the Rust wasm32-unknown-unknown target is still using --export-dynamic, which makes the resulting wasm module export get_global_ptr and set_global_ptr. And there are some other subtle differences between wasm32-unknown-unknown and wasm32-wasi.

How inconvenient would be to use target.polyfill in the config.toml file, and have users build with RUSTFLAGS=--cfg=polyfill, instead of reusing wasm32-unknown-unknown? That way we're not tied to how wasm32-unknown-unknown does things.

[alexcrichton]

I can change yeah, but can you elaborat on "other subtle differences"? I would additionally like to remove the $foo.command_export exports injected by LLD for the wasi target.

Additionally there's no real reason that --export-dynamic is used on the wasm32-unknown-unknown target other than it was literally the only way to do things at the time, but that was years ago and I surmise things have changed in the meantime.

[alexcrichton]

I've added a new commit with a feature that came up yesterday which is to have one build of the adapter for commands and another that's not for commands. The latter should be useful for "my wasm just happens to import WASI" but has its own form of exported interface.

[sunfishcode]

Following up on the discussion above, I submitted some PRs to Rust:

• Stop passing -export-dynamic to wasm-ld. rust-lang/rust#105405 proposes removing the -export-dynamic from wasm32-unknown-unknown.
• Update the wasi toolchain. rust-lang/rust#105395 eliminates the $foo.command_export symbols.

Looking more closely, the other difference I see between wasm32-wasi and wasm32-unknown-unknown is that wasm32-unknown-unknown does options.default_adjusted_cabi = Some(Abi::Wasm); while wasm32-wasi doesn't. I think that only affects structs passed or returned by value, which neither wasi_snapshot_preview1 nor the canonical ABI for wit interfaces have.

[sunfishcode]

Ok, I've now convinced myself that we can do this. If we ever do hit the ABI differences, we should find out about them via link-time signature mismatches.

[alexcrichton]

Thanks for opening those! Also, yeah, we don't have to worry about the cabi bits there. That's basically only for interacting with C code and otherwise wit-bindgen takes care of all the ABI details necessary for the canonical ABI through other means.