Stream: wasi

Topic: wasm-ld for components


view this post on Zulip Randy Reddig (Mar 13 2024 at 18:14):

Is there any intention or desire to directly update wasm-ld to emit components directly? I saw https://github.com/alexcrichton/wasm-component-ld and wondered if some or all of it could be backported to wasm-ld.

Command line linker for creating WebAssembly components - alexcrichton/wasm-component-ld

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:15):

Asking because I’m looking at the Go wasm linker, which doesn’t use LLVM, to figure out how to modify it to directly emit a component.

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:19):

At this time, no, I don't think anyone's looking to port this to wasm-ld. The main complication is the wit-component crate which performs the componentization process. While that can certainly be written in any language it's a pretty tricky piece of code to port so it's not one I think anyone wants to port to C++ yet.

Other than that though it's a trivial wrapper so that's the only hard part

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:19):

(sorry sent soon so updated previous message with what I fully wanted to say)

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:20):

We want to port that logic to Go.

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:21):

Essentially this is a requirement for mainline Go to support WASI Preview 2, which means natively supporting the component model.

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:22):

Sure! In that case the work item is basically the wit-component crate and what it does internally

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:22):

How much (if any) of what wit-component does could be moved to wit-bindgen?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:23):

nothing, unfortunately, because it all operates after the wasm module has been created, whereas wit-bindgen works on things before a wasm module has been created

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:23):

I'll caution you that wit-component is a notoriously subtle crate and does quite a lot internally, but that being said the inputs and outputs are pretty clear so it's also ripe for a second implementation

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:23):

What’s the best way to understand the work that wit-component performs?

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:24):

Is the process documented outside of the Rust implementation?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:24):

Heh unfortunately I don't think I have a great answer other than reading the implementation yeah

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:24):

little of what it does is "standard" per se, but it's becoming sort of defacto standard nowadays

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:24):

Related: is there a second standalone runtime that supports the CM?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:25):

the closest equivalent I'm aware of is jco running components on node

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:25):

Jco leans on the Rust tooling (warm-tools, wit-component) right?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:26):

It does, yes.

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:27):

jco compiles all the rust tooling itself to wasm and then runs that in node to generate code that runs in node

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:27):

(sort of self-hosting I believe)

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:28):

Oh interesting.

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:29):

Observation: the name mangling and metadata added in wasm-tools component embed and component new are workarounds for limitations in LLVM tooling for C/C++/Rust?

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:31):

How much of the subtlety/complexity of wit-component has to do with adapters?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:32):

sort of and sort of not, the decision with wit-component was to use a core wasm module as the unit of abstraction for creation of a component, so you feed in a core wasm and then out pops a component. Decisions around mangling/metadata were made within that context, everything was about how do we use a core wasm module to represent what a component ought to be.

On one hand that's all a limitation of LLVM in that it can't output components, but it's also an acknowledgement of reality of we didn't want to create a whole brand new "everything" in LLVM centered around components when it's all more-or-less modules anyway.

So sort of a workaround, but also even if it weren't a workaround I think we'd likely settle on this as well

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:33):

How much of the subtlety/complexity of wit-component has to do with adapters?

My gut would be 20%, so some, but not all

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:35):

The major tasks are, off the top of my head:

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:36):

OK I have the deserializing of a Resolve back into WIT working today

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:36):

Ah this is a very different operation, it's basically taking a binary component and deserializing it into a Resolve

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:36):

Ah, OK.

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:37):

In the case of mainline Go, we’d be able to have all this metadata around anyway, when outputting the .wasm file.

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:37):

So we wouldn’t need to stash WIT metadata somewhere for post-processing a module

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:37):

you can see this with wasm-tools component wit -t ./my-wit-folder -- that'll output a wasm component, in its text format, and that's what you would need to parse to get back into the WIT (you'd parse the binary, which you can see with --wasm)

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:38):

Yeah the "smuggle through custom sections" workaround sounds like you could remove, which would be nice

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:39):

Since we’re starting with TinyGo, I do need to do some smuggling as a starting point

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:39):

Do we have sufficient information in the Resolve to embed metadata sections in the generated Go code?

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:40):

That the TinyGo compiler could add as specific sections to the emitted .wasm file?

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:40):

The approach I'm thinking is to emulate the wasm-tools component embed step directly, before trying to emulate warm-tools component new

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:41):

yes that's this function, where all you need is a Resolve and a WorldId and then you can make the custom section

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:41):

What’s the format of that custom section?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:42):

you can find the creation here as well as documentation in that module

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:42):

aka it's a component with a custom section where the custom section has I think maybe 2 or 3 bytes and that's it

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:42):

the component is the "big piece"

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:42):

So it’s the binary representation of wasm-tools component wit -t?

view this post on Zulip Alex Crichton (Mar 13 2024 at 18:42):

indeed yeah

view this post on Zulip Randy Reddig (Mar 13 2024 at 18:43):

OK thanks


Last updated: Dec 23 2024 at 12:05 UTC