search

surma / wasmphobia

https://wasmphobia.surma.technology/
Apache License 2.0
94 stars 5 forks source link

Wasm Component support? #2

Open yoshuawuyts opened 6 months ago

yoshuawuyts commented 6 months ago

Heya! I was trying to upload some of my WASI 0.2 experiments, and I'm getting the following error:

Could not create flamegraph: Error: Unsupported Wasm encoding

I assume this has something to do with Wasm Components not yet being supported? In case you want to test it out, I tried uploading the following wasm binary: manual.wasm.zip. It's a compiled version of this code. Thanks!

surma commented 6 months ago

Yeah I am not surprised. Thanks for the sample file. I’ll take a look if I can easily add this.

surma commented 6 months ago

Gave it a try in #5. Would love your feedback on this.

yoshuawuyts commented 6 months ago

Oh this is great; thank you so much! - I guess next question: there seem to be a number of sections labeled with <no mapping info>. At first I wasn't sure whether this was due to not having set the right debuginfo flags, but here is a version where I definitely have configured it correctly: manual.wasm.zip. This results in this flamegraph, with around 60% of code being labeled as <no mapping info>:

Screenshot 2024-05-12 at 13 13 06

I'm not sure what might be causing this. Until recently debuginfo in Rust was blocked on https://github.com/rustwasm/wasm-bindgen/issues/2389 and https://github.com/rustwasm/walrus/issues/247, but those seem to have been resolved - so I wonder whether this is something in wasmphobia?

yoshuawuyts commented 6 months ago

Ah okay, I just saw your comment in https://github.com/surma/wasmphobia/pull/5#event-12776628877:

Especially curious if me not recursing for nested components is a big deal wrt how useful the flame graph is.

Is this related to the <no mapping info>?

surma commented 6 months ago

So, this seems expected, although I understand that there’s probably more information to extract.

There’s rarely any mapping information in DWARF about the data section, and seemingly also not about the the component-type:bindings section . Looking at the contents of the bindings section, I am not sure I can show anything meaningful there either.

Screenshot of bindings section Screenshot 2024-05-12 at 18 35 06

I was under the impression that — even in the component model — all code from all modules would be in the code section. So I’d expect that DWARF debugging data would provide correct attributions. Am I wrong?

yoshuawuyts commented 6 months ago

So, this seems expected, although I understand that there’s probably more information to extract.

Oh neat, ok! - So for context: I've mostly worked with Components as a consumer, not as an implementer. Same with DWARF. So this is one of my first forays into the lower level internals. You definitely know more about this than I do, so I really appreciate you clarifying and explaining things!

Looking at the contents of the bindings section, I am not sure I can show anything meaningful there either.

Hmmm, that's a good question. So again, I'm not super familiar with the internals of this - but if I'm understanding this right, this is encoded as a custom section with a canonical name using a structured format. For example: bindings contained under wasi:http/proxy (<namespace>:<package>/<world>) could be displayed in a four-tier hierarchy under component-type:bindings, then <namespace>, then <package>, then <world>. If a package is particularly heavy on bindings (thinking about a potentially auto-generated "browser" world here), just even knowing the binding size of individual worlds would be incredibly useful to have insight into!

I was under the impression that — even in the component model — all code from all modules would be in the code section. So I’d expect that DWARF debugging data would provide correct attributions. Am I wrong?

That's a good question too, and I don't have an answer to that right now. I'll ask around on the BA Zulip; someone there will likely be able to answer this. Let me get back to you!

yoshuawuyts commented 6 months ago

Okay, asked around for that last question - it seems this is almost certainly a DWARF insertion bug somewhere. Either in the Rust compiler, in LLVM, or in some optimization tool we're running. Unclear right now and folks want to look into this further; but the good news is that wasmphobia probably doesn't need to do anything to address this and we can just fix this somewhere upstream.

surma commented 6 months ago

Thanks so much for digging into this! Keep me posted and let me know if I need to adjust anything on this end :)

yoshuawuyts commented 6 months ago

Alex Crichton chimed in on Zulip. I figured I should just paste this in full, since he's asking some interesting questions:

Reading over the component support I think that there may need to be a bit more refactoring to support components. Right now it's slurping all dwarf sections into one object when each core wasm module will need to be treated separately. I'm not sure if that'd explain the current thing you're seeing though, it depends on the size of the component. Additionally though there's going to be multiple code sections within a component so it'd be good to confirm that the dwarf info is relative to the right code section start.

Additionally though I see that the "component-type" custom section is in the component that has a flame graph, but that should be stripped out by wit-component when a component is created, so that's also suspect (but perhaps just a bug in wit-component?)