Currently, we emit basic DWARF information and our target debuggers (LLDB and the DevTools extension) are more or less able to consume it.
We should do much more. WASM debugging story is somewhat infamously lacking in a number of areas, so a lot of this issue will be about upstream (but not necessarily /runtime) work. Note as well that this issue is about native debugging. If/when NAOT gets investment in the direction of managed debugging, that I am sure will have rather separate concerns.
But first, some obvious things we need to address on our side:
1) Add debugging tests.
2) Emit DWARF for funclets so that they can be stepped through.
3) Emit DWARF for statics so that they can be inspected.
Support C++-style dynamic type discovery via vtables.
Support automatically stepping over helpers such as allocators and similar "artificial" code. Introduce this under an undocumented switch so that debugging the runtime itself is still possible.
Support pretty-printing of strings and arrays. There is support in DWARF for specifying the length dynamically but it's not picked up by the Chrome debugger (naturally, as C++ doesn't use it). Will involve wasmtime work in translation, may even involve LLDB work (whether it supports dynamic length discovery needs to be checked). Upstreamable.
Bonus points for supporting MD arrays.
Support scoping by translating CLI namespaces to C++ namespaces.
Drop mangled type names in DWARF.
It is not clear why mangled names are used right now. Upstreamable.
Drop mangled method names from the names section. C++ doesn't emit them. If LLVM simply demangles C++ mangling this may involve upstream LLVM work.
Support calling methods with LLDB.
Upstream work in wasmtime/LLVM. Last I checked there is no support for calling C methods either.
In parallel, we should pursue improvements to the overall ecosystem with the following end goal: it is possible to produce highly optimized WASM with a separate debug info file, which could be used to debug rich WASM core dump files. Basically, parity with other native experiences.
The exact work items in this direction are TBD, but the first problem to solve is the "optimized" part. As https://github.com/dotnet/runtimelab/issues/2357#issuecomment-1661108919 shows, currently, debug must be dropped if you do not want to give up on shrinking relocations (essentially, a post-link optimization). DWARF is a fragile format as it operates on exact offsets within functions for things like location lists, which is not terribly compatible with post-link optimizations. Current solutions in tools like wasm-opt employ expensive DWARF parsing and writeback to solve this. The task here is to design a scheme that would allow for relocation shrinking in the linker at a lower cost (both in terms of performance and complexity).
SingleAccretion
commented
7 months ago
Currently, we emit basic DWARF information and our target debuggers (LLDB and the DevTools extension) are more or less able to consume it.
We should do much more. WASM debugging story is somewhat infamously lacking in a number of areas, so a lot of this issue will be about upstream (but not necessarily
/runtime) work. Note as well that this issue is about native debugging. If/when NAOT gets investment in the direction of managed debugging, that I am sure will have rather separate concerns.But first, some obvious things we need to address on our side: 1) Add debugging tests. 2) Emit DWARF for funclets so that they can be stepped through. 3) Emit DWARF for statics so that they can be inspected.
In parallel, we should pursue improvements to the overall ecosystem with the following end goal: it is possible to produce highly optimized WASM with a separate debug info file, which could be used to debug rich WASM core dump files. Basically, parity with other native experiences.
The exact work items in this direction are TBD, but the first problem to solve is the "optimized" part. As https://github.com/dotnet/runtimelab/issues/2357#issuecomment-1661108919 shows, currently, debug must be dropped if you do not want to give up on shrinking relocations (essentially, a post-link optimization). DWARF is a fragile format as it operates on exact offsets within functions for things like location lists, which is not terribly compatible with post-link optimizations. Current solutions in tools like
wasm-optemploy expensive DWARF parsing and writeback to solve this. The task here is to design a scheme that would allow for relocation shrinking in the linker at a lower cost (both in terms of performance and complexity).