Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support debug traces #137

Open
guybedford opened this issue Sep 16, 2024 · 10 comments
Open

Support debug traces #137

guybedford opened this issue Sep 16, 2024 · 10 comments

Comments

@guybedford
Copy link
Collaborator

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

@thesuhas
Copy link
Contributor

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.

@guybedford
Copy link
Collaborator Author

Error stacks simply don't work when there are panics in the StarlingMonkey runtime, even when pointing to the debug build (eg see #138).

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

@thesuhas
Copy link
Contributor

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

@guybedford
Copy link
Collaborator Author

@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?

@thesuhas
Copy link
Contributor

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

@thesuhas
Copy link
Contributor

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!

@guybedford
Copy link
Collaborator Author

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

@thesuhas
Copy link
Contributor

thesuhas commented Oct 2, 2024

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

@cataggar
Copy link
Contributor

cataggar commented Oct 9, 2024

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.

@guybedford
Copy link
Collaborator Author

This is currently blocked on bytecodealliance/StarlingMonkey#173.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants