Readable Wasm Exceptions

[andreaTP]

Currently, when we hit an unreachable opcode we simply blow up the Machine.

The call stack contains information about the function names, but they are obscure for the user that needs to do the mapping functionIdx -> function name in the custom section.

This can be automated using the StackWalking API, that can kick in only when unreachable is reached.

[LDemetrios]

+1 on that one!
I recently started a big project using Chicory (library I'm connecting is written in Rust), and discovered it's very tricky to debug, as every panic!() just jumps to abort function, and panic hooks are uncapable of retrieving backtrace. If HostFunctions throw exceptions, the call stack consists of call() methods with no real meaning. Replacing stack trace elements of the exception would certainly help with the latter, but not with the former -- personally, I would having a method to retrieve current stack trace, which can then be called from a host function.

[andreaTP]

Hi @LDemetrios and thanks a lot for your interest in this project!

Where we left is this PR: #937 and the follow up.
Unfortunately, seems like there is not enough detail on the Wasm Specification side to allow for a consistent implementation at this point in time.

I encourage you to try things out and report any feedback.

[LDemetrios]

Hi @LDemetrios and thanks a lot for your interest in this project!

Where we left is this PR: #937 and the follow up. Unfortunately, seems like there is not enough detail on the Wasm Specification side to allow for a consistent implementation at this point in time.

Thank you very much! I am very okay with mangled function names, so this is enough, I just copied code of WasmModule::functionName xD.

[andreaTP]

Good to hear that you have a viable workaround @LDemetrios !

[headius]

I am also interested in this work and have a few suggestions (or questions) for future plans.

• Post-processing exceptions with StackWalker makes sense.

We use this in JRuby to rewrite interpreter frames and mangled native frames into a consistent Ruby stack trace. This only helps exception traces, though, and won't do anything to make the code more debuggable.

• The generated "func_###" names I see in AOT must relate back to something from the original source, so why do they not reflect that?

I assume these are essentially basic blocks from the original code, broken up and compiled into individual methods. Could they be prefixed with the function name, at least? "pm_serialize_parse$func_123" would get me much closer to being able to debug things when they go wrong.

• Other debugging elements could be injected intothe JVM bytecode

Obviously without something like DWARF we can't really map to source line numbers (this work should continue but I know there's challenges) but other JVM debug information could be provided to at least let step-debugging see more useful live frames.

Happy to help where I can!

[andreaTP]

I assume these are essentially basic blocks from the original code, broken up and compiled into individual methods.

We don't control it, but yes, they usually match, the challenge is that different languages are emitting the names in different formats, so we probably need something pluggable.

other JVM debug information could be provided to at least let step-debugging see more useful live frames.

I have very very limited expertise, but I'm all hears on how to improve this aspect!