ComponentizeJS Support debug traces

Currently when the Wasm engine panics, it's impossible to figure out where in StarlingMonkey / ComponentizeJS the panic happened.

For debugging these kinds of errors it would be much easier if we could have a debug build with at least the names section.

We do have a build:debug in this repo, and it does work using RelWithDebugInfo.

But when using the splicer, this information is dropped from the binary - if we maintain these debug sections in splicing that would be beneficial, ideally also fixing their offsets to match the operations performed by the splicer.

//cc @thesuhas

Sep 16 '24 17:09 guybedford

Do you mean that the debug sections are getting stripped? Currently orca reencodes all custom sections other than the name section as is, and the name section is updated in case of change of any names.

Sep 18 '24 17:09 thesuhas

Error stacks simply don't work when there are panics in the StarlingMonkey runtime, even when pointing to the debug build (eg see https://github.com/bytecodealliance/ComponentizeJS/issues/138).

Perhaps there's a simple fix indeed. Although I thought that the import offsets was affecting this.

Sep 18 '24 19:09 guybedford

What information is used or accessed to get the error stacks? Is there a specific section in the wasm binary that encodes this?

Sep 18 '24 19:09 thesuhas

@thesuhas the DWARF info is read, but primarily the direct information needed comes from the "name" section of the binary as well.

I think we can get quite far here if we can just properly update the "name" section to reference the new indices with the transformations performed by the splicing code, even if we don't provide full DWARF rewriting yet.

The name section itself is described here - https://webassembly.github.io/spec/core/appendix/custom.html#name-section. Does Orca handle rewriting indices in this section to match the alterations?

Sep 24 '24 17:09 guybedford

I do believe orca does handle this but there may be some bugs in this process. I shall test it more and get back to you

Sep 26 '24 12:09 thesuhas

It looks like there was a bug when an imported function was converted to local, the name would not be copied over. So in the case of ComponentizeJS where this is a very common operation, the names were lost in the process. I've added this functionality now, will update once a release has been successfully made!

Sep 26 '24 20:09 thesuhas

Thanks so much for following up on this @thesuhas look forward to trying it out when it's ready.

Sep 27 '24 16:09 guybedford

Hi! We just made a new release of orca with that bug fix included! Please let me know if that fixes the names from disappearing

Oct 02 '24 22:10 thesuhas

Awesome. Looks like updating to orca 0.1.2 or higher should have it https://crates.io/crates/orca-wasm/versions . 0.1.4 is the current latest.

Oct 09 '24 01:10 cataggar

This is currently blocked on https://github.com/bytecodealliance/StarlingMonkey/issues/173.

Oct 30 '24 01:10 guybedford

I'm happy to see that https://github.com/bytecodealliance/StarlingMonkey/issues/173 was resolved a couple of weeks ago. Did it unblock this?

Feb 05 '25 22:02 cataggar

Thanks for the ping @cataggar - I just tested and yes this does finally work now! Note this is just the function name list for the stack and nothing more, although @tschneidereit has some upcoming full debugger support in https://github.com/bytecodealliance/StarlingMonkey/pull/219.

PR up in https://github.com/bytecodealliance/ComponentizeJS/pull/192.

Feb 22 '25 00:02 guybedford