-
Notifications
You must be signed in to change notification settings - Fork 282
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
Implement backtraces in wasmi
#538
Comments
Past discussions on |
It might be a better idea to generate a coredump on trap. Then the debug information doesn't need to be attached to the wasm binary and parsed by wasmi. That's one of the debug modes that is supported by wasmtime and wasmer. Would you be interested in me sponsoring your work on this issue? I'm making Firefly Zero, a wasmi-powered handheld game console, and tracebacks is the most requested feature gamedevs have so far. With the current implementation, if a trap occurs, I can only provide information about the guest function that failed and the last called host function. |
Hi @orsinium, very cool to hear about Firefly Zero and that it uses Wasmi. :) I absolutely love the mascot and the idea. I personally have not yet taken a look into the technical aspects of coredumps and what is going to be necessary for Wasmi to support producing them when encountering a trap but will take a look as I think it is a very valuable addition to Wasmi. What do you mean by sponsoring exactly? Implementing it yourself and sponsoring a PR? (great if it meets the quality) Or sponsoring this feature monetarily for me to implement? |
The latter. I looked around to see if there is a link to financially sponsor you or wasmi and haven't found any. I want to support the most important project that powers Firefly Zero, especially if it can bring closer some of the important features like the one in question. I could also look into implementing coredumps for wasmi myself but I'll have the capacity only in October. |
It shouldn't be that hard! This repo contains some Rust libraries and tools: https://github.com/xtuc/wasm-coredump The most important one for us is wasm-coredump-builder: https://docs.rs/wasm-coredump-builder/0.1.22/wasm_coredump_builder/ The docs above have a code example: let mut coredump_builder = wasm_coredump_builder::CoredumpBuilder::new()
.executable_name("/usr/bin/true.exe");
{
let mut thread_builder = wasm_coredump_builder::ThreadBuilder::new()
.thread_name("main");
let coredump_frame = wasm_coredump_builder::FrameBuilder::new()
.codeoffset(123)
.funcidx(6)
.build();
thread_builder.add_frame(coredump_frame);
coredump_builder.add_thread(thread_builder.build());
}
let coredump = coredump_builder.serialize().unwrap(); So, all you need to provide it is the instruction and function offset for each frame in the trace. Then people can use wasmgdb from the same repo to map the coredump to a DWARF to produce a proper traceback. |
Interesting, just today I was thinking about making use of GitHub sponsoring system but wasn't sure if anybody would actually use it. 🤔 Need to think about it. Thanks for the |
It's not that hard to add no_std support in there! There is not that much code, and seems like only |
I drafted a PR for lb128 as well: It's not as pretty as I wish it was and there are a few small things left to implement. Let's see what the Gimli core team folks say. |
|
Hi @orsinium, that's pretty cool news! Looking forward to see a PR. :) I think the Bytecode Alliance is more open to |
I managed to drop wasm_encoder! Now the whole thing is 126 lines. I'll test it next week and then it's ready. |
The code is ready! With a few quick tests, it seems like my implementation works even better than wasm-coredump-builder. I've made it no_std, zero-dependency, with far fewer allocations, and even found and fixed a few bugs along the way. Now, how do you want to proceed? I can make a separate repo and crate or we can keep things simple and put it right into wasmi. I don't mind either option, I do it not for fame. |
Even though
wasmi
is an interpreter VM for Wasm we are missing proper debugging functionality such as backtraces.This is a heavily requested feature by smart contract users so that they can finally properly debug and analyze their smart contract exeuctions.
Having backtraces is not sufficient by its own since we also are required to show proper function and local variable names for a nice debugging UX. For this purpose we also need to support the Wasm
name
section that provides a Wasm VM with those names for a given Wasm blob.Furthermore any backtrace implementation for
wasmi
should ideally not conflict with the performance in case those backtraces are not required. Therefore we need to find a design that has zero cost for non-debug executions.@cmichi
ToDos
name
section.wasmi
execution debugging without overhead of non-debug executions.Related Work
Config::wasm_backtrace
: https://docs.rs/wasmtime/2.0.0/wasmtime/struct.Config.html#method.wasm_backtraceConfig::wasm_backtrace_details
: https://docs.rs/wasmtime/2.0.0/wasmtime/struct.Config.html#method.wasm_backtrace_detailsThe text was updated successfully, but these errors were encountered: