-
Notifications
You must be signed in to change notification settings - Fork 32
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
Comments
Do you mean that the |
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. |
What information is used or accessed to get the error stacks? Is there a specific section in the wasm binary that encodes this? |
@thesuhas the DWARF info is read, but primarily the direct information needed comes from the I think we can get quite far here if we can just properly update the 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? |
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 |
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 |
Thanks so much for following up on this @thesuhas look forward to trying it out when it's ready. |
Hi! |
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. |
This is currently blocked on bytecodealliance/StarlingMonkey#173. |
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 usingRelWithDebugInfo
.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
The text was updated successfully, but these errors were encountered: