Hello,
I'm trying to get debugging set up for Nim in VS Code. I'm using this VS Code extension: https://marketplace.visualstudio.com/items?itemName=nimsaem.nimvscode and I followed the instructions listed on that page, except for installing lldb (since gdb seems to be already installed and it looks like CodeLLDB supports gdb). Debugging seems to be sort of working, but the variables listed in the debugging window are mangled somewhat - e.g. the listing for a variable named "idx" is listed as "idx__d4948p49_25" and is in the "static variables" section despite being a local. Breakpoints might also be broken, I can't quite tell.
I can post more details if needed, but is this a known issue with gdb v.s lldb, or that Nim extension, or something along those lines? I can try to install lldb and give that a shot, but it seems to be complicated since I'm on Windows, and googling around I didn't really get the sense that it would improve anything.
it's a bit of an unfortunate thing to say, but it's not going to get much better than this.
If you haven't been using --debugger:native already, that does makes some things like breakpoints work atleast in theory. Though if you have ever debugged C++ code, you know that when turning on the slightest optimisations, things can already get messy. Add another layer on top and you set a breakpoint and it might trigger a bit above or below, it might also just never trigger at all.
There was a GDB Python script which did some demangling, but supposedly it never worked that well or at all with GDB GUIs, it only ever worked with the old runtime (so pre arc/orc) and to my knowledge hasn't really been maintained.
This, after NimSuggest/intellisense is the biggest issue on Nim's tooling turning people away. Not sure where the fix would go TBH. Does it require the compiler to do something additional on the emitted symbols? Maybe to dont mangle or remap them to something the debugger can understand if in debug?
When you interop with a C/C++ library with Nim those symbols are just fine
Agreed. The debugging situation is not great and a large part of the whole poor tooling situation.
Out of curiosity, C++ does name mangling too IIRC? How is that handled by gdb? Is it possible to map the non-mangled symbols in the DWARF data?
I'm sorry but it's somewhat incredible how much noisy talk there can be dancing around the very simple facts: """
Nimsuggest while perhaps not being bottomlessly feature rich has the exact right QnA design architecture to be integrative and holisitc with more PR's
IC is a cool goal as it pertains exactly to the core question of a compiler, "Has this been sufficiently compiled already?", "is other recompilation neccesary or sufficient" but it's a hard one with much unexplored territory.
Nim teaches that any sufficiently extensible software architecture is indistinguishable from writing a parser. """
Parsing can get real tricky though, this is also why the VSCode Nim plug in still has 'simple' bugs in its interface to nimsuggest despite numsuggest providing the capabilities.
Tooling needs an iPhone level interface jump, but this is not just true for Nim, and there are plenty of babblings on most forums about this ultimate IDE GUI that'll save us all.
Nimsuggest PR's, Stdlib PR's, Nimedit PR's, Etc. Etc. Aren't as hard as you think, but probably just as tedious.
For what it's worth, I have the same problem when following the installation steps, so with CodeLLDB.
I have tested with Windows 10 and Manjaro Linux. LLDB has a notoriously bad compatibility with Windows binaries from what I've read, and the problems I've seen with this Nim extension are similar to what I've experienced with Rust: poor variable visibility and unreliable "step" operations. But in this case, it's the same with Linux, which is surprising.
I've noticed that the variables are only mangled and located in the static tab outside of procedures. I think global variables may indeed static but I couldn't find any confirmation.
In a procedure, you'll see the variables with their actual names but there are also other mangled variables that don't seem relevant to the user.
Likewise, "step over" actually perform "step into", for example in for loop iterators, and breakpoints don't always work or the program sometimes stops where there is no breakpoint.
Obviously in both issues, some information is missing or is not well adapted to the debugger. I'm not sure if that's because Nim is a transpiler, or if that's simply work in progress on the interface to LLDB. At least it allows some form of debugging.
(Crossposting these tips as they seem equally relevant here...)
Without diminishing the importance of better "out of the box" tooling for Nim, here are some tricks that have improved my experience a lot:
https://marketplace.visualstudio.com/items?itemName=geddski.macros
"macros": {
"runToNextLine": [
"editor.debug.action.toggleBreakpoint",
"cursorDown",
"editor.debug.action.toggleBreakpoint",
"workbench.action.debug.continue",
]
}
https://github.com/saem/vscode-nim/issues/59 https://www.reddit.com/r/nim/comments/lhaaa6/debugging_support_formatters_for_lldb_in_vscode/
IMPORTANT: These currently only work when using the (soon-to-be-legacy) --mm:refc memory manager.
It's certainly not ideal that the best debugging experience is obtained by copy-pasting some python code from Reddit. FWIW, there's no fundamental reason why this can't all be more streamlined with some updates to the VSCode plugin for Nim.