GSoC Workspace: Implementing Coredump for Post-Mortem Debugging in WebAssembly about wasmedge

[hydai]

Hi @sid-008
Do you have any updates on this issue? Please update us on the progress every week to meet the policy. Thanks!

[sid-008]

Hi @sid-008
Do you have any updates on this issue? Please update us on the progress every week to meet the policy. Thanks!

Hey Hydai,

Sure, I will do the needful shortly on the github issue.

[sid-008]

Community Bonding Period [1st May, 2024 to 26th May, 2024] - status update

• LLVM coding style has to be followed - .clang-format and .clang-tidy
• Implementations of coredump in other runtimes has been done using the wasm-coredump-builder rust crate.
• The coredump file itself must be encoded using the Wasm encoding format.
• End result should be a flag that enables generation of a coredump file that can be debugged using tools such as wasmgdb

[sid-008]

Preliminary Analysis of existing Implementations of coredump generation and related tooling

• wasmgdb seems to have a future dependency issue with the use of its wasmparser module.

warning: the following packages contain code that will be rejected by a future version of Rust: wasmparser v0.57.0

• Current implementations rely on the wasm-coredump-builder and the wasm-coredump-rewriter
• What coredump-builder is doing relies on the polyfilling technique this kind of approach may not be suitable for the project due to its reliance on external dependencies including a implementation to rewrite Wasm binaries that has been written in AssemblyScript (see: blog on Wasm Coredump rewriter)
• The binary is essentially rewritten to support calls to an external library(I think) by calls such as:
  call $coredump/write_coredump
• There's also a few things to keep in mind with regards to the above implementation of coredump, including:

Wait, what’s this about the first 1 KiB of the memory being unused, you ask? Well, it turns out that most WebAssembly linters and tools, including Emscripten and WebAssembly’s LLVM don’t use the first 1 KiB of memory. Rust and Zig also use LLVM, but they changed the default. This isn’t pretty, but the hugely popular Asyncify polyfill relies on the same trick, so there’s reasonable support until we find a better way.

• As per prior discussions as well; we would like to have a standalone implementation for coredump to enhance the robustness of this feature.

Proposed approach:

• The flag currently to enable coredump has been added.
• My current approach would be to take information from the executor and try to construct the coredump file from an instantiated wasm binary.
• A snapshot of the linear memory could be taken using helper functions like getBytes of the MemoryInstance class.
• The StackManager class and its methods would be useful in helping unwind the stack and accessing the values in locals (includes function parameters)
• It would be a correct approach to create a new class for coredump building, similar to how statistics has been implemented.

[sid-008]

Current Status

• WasmEdge can encounter traps under various conditions(See: Wasm Security model, Traps.
• One instruction in particular traps execution unconditionally. This is the unreachable instruction.
• Current discussed approach is to implement the coredump pipeline for the unreachable instruction and then use that pipeline for other cases.
• The execution flow for the unreachable instruction to be encountered has been identified, a seperate coredump class has been created to collect relevant information and write out the coredump file.
• There are 6 distinct custom sections. Information for each can be fetched from the executor.
• A draft PR (#3521) has been opened.