wasip2: Improve "command" startup flow #710
Conversation
| exit_result_void_void_t status = { .is_err = true }; | ||
| exit_exit(&status); | ||
| } | ||
| return r != 0; |
There was a problem hiding this comment.
Why is the exit call no longer needed?
There was a problem hiding this comment.
With a target-specific entrypoint signature I was able to update to directly return the result that the wasi:cli/run entrypoint returns rather than being required to go through the wasi:cli/exit route. A bit of a nice benefit as programs will now actually naturally return as opposed to prior where they would unconditionally raise a trap to exit.
| else() | ||
| # wasip2+: crt1-command.o is modified from what CMake produces to | ||
| # additionally have a custom section representing the type information needed | ||
| # for its contained export. This is the `wasi:cli/run` interface, for example. |
There was a problem hiding this comment.
Would it be hard to add an assembly syntax for this so that clang/llvm can produce this object file without needing external tools?
There was a problem hiding this comment.
I poked at that a bit, but was unfruitful in my ability to get it working. That being said you probably know whether this is possible more than I, so question for you!
The need here is that a custom section needs to be located inside of crt1-command.o (wasm custom section, not linking custom section). This wasm-tools command will embed the data within the object with a particular section name. We can pretty easily generate the data to embed ahead-of-time (similar to how wit-bindgen-generated bindings are checked in to this repo). Effectively what I want is something like:
__asm__(
".custom_section.component_type:other:naming:information"
#embed <the_world.wasm>
);
or... something like that. I couldn't figure out either .custom_section for __asm__, #embed, nor how to emit a wasm.custom_section in Clang via a C global or something like that. Do you know if these are all possible to combine?
There was a problem hiding this comment.
That looks like something that it should be possible to support with the asm syntax yes. Assuming that #embed plays nice with __asm__ in general (i.e. on other platforms) i don't see why it shouldn't for us.
BTW, In this case are you actually embedding a wasm file as a custom section in another wasm file (i.e. the object file)?
There was a problem hiding this comment.
Oh my problem is I can't actually figure out a syntax/incantation that works. I suspect something like this should work, but I'm not enough of a clang wizard to figure it out.
And yeah, the type information for components is itself a component (a wasm file) which is embedded in objects.
alexcrichton
force-pushed
the
better-startup
branch
from
762df28 to
f6ad2a8
Compare
This commit is an improvement to the WASIp2 target which changes how the interface `wasi:cli/run` is defined and exported. Previously the `wasm32-wasip2` target would define a `_start` wasm export which required the use of the WASIp1-to-WASIp2 adapter to hook it up to `wasi:cli/run`. This meant that despite libc not actually using any WASIp2 APIs the adapter was still used. The purpose of this commit is to change this. The changes made here are: * The linker-level `_start` symbol now has a wasm-level export name of `wasi:cli/run@0.2.0#run`. This means that `_start` isn't a wasm-level export any more, meaning there's nothing for the adapter to import. * The signature of the C-level `_start` function is now different based on WASI version (returns an `int` in WASIp2, nothing on WASIp1) * The `crt1-command.o` object file now contains type information for `wasi:cli/run` (which previously wasn't present anywhere in wasi-libc). This means that when this object is linked in `wit-component` will know what to do after linking. The end result is that binaries are now produced entirely without the WASIp1-to-WASIp2 adapter and linking with `-Wl,--wasi-adapter=none`, for example, produces a working binary. Another minor change made in this commit is that the `crt1-*.c` files are now included in `clang-format` like all other source files. Build-wise this requires the usage of `wasm-tools` at build-time to embed type information in the clang-produced object file for `crt1-command.o`.
alexcrichton
force-pushed
the
better-startup
branch
from
f6ad2a8 to
524ce79
Compare
| // that this shouldn't be too problematic (in theory). | ||
| __attribute__((export_name("wasi:cli/run@0.2.0#run"))) int _start(void) | ||
| #elif defined(__wasip3__) | ||
| __attribute__((export_name("wasi:cli/run@0.3.0-rc-2025-09-16#run"))) int |
There was a problem hiding this comment.
Isn't wasi:cli/run.run an async function in wit, and thus would need a different annotation and a callback companion entry point? I guess this can work because the runtime adapts this blocking implementation?
4 participants
This commit is an improvement to the WASIp2 target which changes how the interface
wasi:cli/runis defined and exported. Previously thewasm32-wasip2target would define a_startwasm export which required the use of the WASIp1-to-WASIp2 adapter to hook it up towasi:cli/run. This meant that despite libc not actually using any WASIp2 APIs the adapter was still used. The purpose of this commit is to change this.The changes made here are:
_startsymbol now has a wasm-level export name ofwasi:cli/run@0.2.0#run. This means that_startisn't a wasm-level export any more, meaning there's nothing for the adapter to import._startfunction is now different based on WASI version (returns anintin WASIp2, nothing on WASIp1)crt1-command.oobject file now contains type information forwasi:cli/run(which previously wasn't present anywhere in wasi-libc). This means that when this object is linked inwit-componentwill know what to do after linking.The end result is that binaries are now produced entirely without the WASIp1-to-WASIp2 adapter and linking with
-Wl,--wasi-adapter=none, for example, produces a working binary.Another minor change made in this commit is that the
crt1-*.cfiles are now included inclang-formatlike all other source files.Build-wise this requires the usage of
wasm-toolsat build-time to embed type information in the clang-produced object file forcrt1-command.o.