Support for Wasm Coredump

[xtuc]

Motivation

When the Wasm instance traps, it's sometimes difficult to understand what happened. Post-mortem debugging using coredumps (which is extensively used in native environment) would be helpful for investigating and fixing crashes.

Demo from a developer's point of view: https://github.com/xtuc/wasmgdb/wiki/Demo.

Proposed solution

Implement Wasm coredumps as specified by https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md. Note that the spec is early and subject to changes. Feedback very welcome!

Additional context

Wasm coredump is especially useful for serverless environment where production binaries are stripped and/or have access to limited logging.

[syrusakbary]

Hey @xtuc , thanks for opening the issue.

We would love to support wasm coredumps, but we are a bit constrained on resources. However, if you would like to help us on that quest we would be more than welcome to accept any improvements/patches towards that goal!

[xtuc]

@syrusakbary I will give it a try. I believe I can use the Backtrace information when a RuntimeError and/or Trap occurs. This should give us a initial / basic coredump implementation.

Please free to send any other pointers if you have something in mind.

[syrusakbary]

Awesome, I believe RuntimeError and backtrace info as you mentioned should make wasm coredump possible.

If you have any questions upon implementing things please let us know on this thread and we will assist!

[xtuc]

@syrusakbary I opened https://github.com/wasmerio/wasmer/pull/3626 for adding basic coredump generation using the existing APIs.

It's inpired by the change I did for wasmtime and wrote some documentation: https://github.com/bytecodealliance/wasmtime/blob/db931d7a93208738b8106e8d8c1a4afc8efaca6d/docs/examples-coredump.md.

[xtuc]

Basic coredump generation has been merged (thanks!).

Now, to have the complete debugger experience, we need to collect the following information:

• Wasm locals of each stack frames; when discussing with wasmtime and having a look at the code myself, support in cranelift is going to take a significant effort. Would the implementation in the LLVM backend be easier for wasmer?
• Snapshot the Wasm instance memory; sounds relatively easy.

[syrusakbary]

Would the implementation in the LLVM backend be easier for wasmer?

Probably. In the past (wasmer 0.x) we used LLVM stack maps for tracking traps, so I believe it shall be doable

[syrusakbary]

Probably @ptitSeb can chime in with more thoughts here

[ptitSeb]

I guess we are talking about tracking the locals in eh_frame/dwarf stuff. I would like to work on something like that yes, but I'll probably start on the singleplass, because this is were I have the more control. It might be easy on LLVM, but I don't know the whole API well enough to say for now.

[ptitSeb]

PR merged, closing.

[xtuc]

The merged PR only has a limited support to Wasmer, most of the features aren't implemented because we are missing access to locals and main memory.

[syrusakbary]

Should we keep the issue open then @xtuc? Would you like to work on the missing features?

[xtuc]

@syrusakbary I'm not familiar enough to do it myself

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[theduke]

Not stale.