Hi,
I made a debugger (gdb/lldb) proxy to intercept communication between vscode and gdb/lldb, so that I can demangle/mangle the symbol names:
https://github.com/YesDrX/nimdebugger
Hopefully, that can help reduce noises during debugging. Currently, only support Linux/Mac.
Linux/WSL
{
"name": "Debug Nim",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/${fileBasenameNoExtension}",
"miDebuggerPath": "${userHome}/.nimble/bin/nim_debugger_mi", //nimble install nim_debugger_mi
"miDebuggerArgs": "", // you may specify gdb path by --gdb-path=/path/to/your/gdb
"MIMode": "gdb",
"args": [],
"cwd": "${workspaceFolder}"
}Mac (Apple Silicon)
{
"name": "Debug Nim",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/${fileBasenameNoExtension}",
"miDebuggerPath": "${userHome}/.nimble/bin/nim_debugger_mi", //nimble install nim_debugger_mi
"miDebuggerArgs": "--lldb", //if --lldb is specified, it will try to load lldb-mi from ms-vscode.cpptools; you may specify --lldb-path as well
"MIMode": "lldb",
"args": [],
"cwd": "${workspaceFolder}"
}Awesome! This is the solution to a Nim debugger in my opinion. Aside from fixing gdb/ldb to understand Nim which isn't likely.
A custom debugger could work but wouldn't have much better metadata than the current system does and that'd be after a ton of effort to even match the DWARF metadata. DWARF produces more than enough info. GDB and LDB just don't know how to use it properly for Nim and don't provide the hooks to demangle variable names, etc.
The proxy layer in the modern LSP's however are ideal for this though. You could in theory add support for Nim async libs as well which a normal debugger won't understand either.