We are aware of the need for this and have experimented with various approaches in the past:
- using Visual Studio to debug a translation of non-IC Motoko Wasm to .NET IL, exploiting the rich debugger of VS.
- using wasm sourcemap and name section info to debug non-IC Motoko Wasm code in a browser (e.g. Chrome or Firefox), debugging using the developer tools.
- adding Dwarf 5 debug info to wasm code to enable debugging of non-IC Wasm via wasmtime and lldb.
- the recent motoko-vm project adds time-travel debugging to a Motoko interpreter, but is not yet at full parity with Motoko and IC features.
The first three would be suitable for debugging library code, not full canisters.
The last will hopefully span more scenarios.
None of the early approaches gave you the full debug experience of a symbolic source code debugger people have come to expect for languages like C# and Java, but some weren’t terrible. Part of the problem is that debug support for Wasm itself is not great and doesn’t seem to be receiving enough attention, for example, there is no standard for full debug information so efforts seem to abuse existing format like Dwarf and JS sourcemaps, which aren’t necessarily a good fit.