Looks interesting, but why would I need to debug wasm binaries when I could debug directly the rust code? And why would I want to convert it to wasm? In order to run it in the browser, right?
As for your second question... there's motion towards making wasm runtimes other environments, like devices or server-side. Kind of like the JVM or CLR, but closer to the metal (e.g. no garbage collector). The advantage of the server-side is the same as node.js, sharing code with the client. The advantage for other environments is a portable file format with performance characteristics closer to native. My impression is that the reception is less enthusiastic than wasm in the browser.
I think the intention of OP is that you compile the same Rust code to a native x86 or ARM binary and debug that. Most bugs are ISA-agnostic so that approach totally makes sense in many situations.
That's how I'm debugging my WASM code compiled from C/C++, and that also works automatically with IDE debuggers that don't know about WASM (like Xcode's or Visual Studio's).
In typical applications, the vast majority of bugs should happen in the platform-agnostic parts, so debugging a native build totally makes sense. It would still be great if WASM would be as trivially debuggable as native code.
IMHO proper source-level debugging support in the browser dev-tools (or remote-debugging via VSCode) would make a lot more sense than debugging in gdb/lldb though.
So there's effectively another layer of sandboxing versus a native binary, and you might need to track down how your program behaves in that sandbox.
Similarly, if you're working with a program that imports several WebAssembly modules, you'll need a way to debug the combined system, versus any single module in isolation.
This post is specifically "Debugging WebAssembly Outside of the Browser," but the title on HN was unfortunately truncated.