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.
- fixed argument parsing
- add Windows support
Very interesting. @YesDrX, do you believe this project would work with a device on a serial port running GDB Server?
I'm thinking about this setup: a host PC with VSCode and the Nim source project, a Black Magic Debug device connected on one side to the PC's serial port and connected on the other side to a microcontroller.
Traditional way
VSCode/Cursor <----MI-----> GDB/LLDB (which will call some executable)
With nim-debugger-mi
VSCode/Cursor <----MI-----> Proxy <----MI--->GDB/LLDB
Here MI is the stdin/stdout/stderr text protocol used by GDB/LLDB. Now in the context of JTAG
Traditional way (ESP32 for example)
VSCode/Cursor <----MI----> esp32-elf-gdb <---TCP---> JTAG <---Serial---> ESP32
With proxy
VSCode/Cursor <----MI----> Proxy <---MI---> esp32-elf-gdb <---TCP---> JTAG <---Serial--->ESP32
So essentially, the proxy will talk to the same GDB backend in MI protocal.
What is missing.
- I have not checked how to parse symbols (some similar debug info there?) in ELF file and construct a symbol mangle/demangle mapping.
- Debugging embedded might be tricky, as there are limits on how many breakpoints to set and things like that.
I don't have a JTAG to play with, maybe I can order one. Did you try something like below to debug in vscode?
// .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "ESP32 JTAG Debug",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/${workspaceFolderBasename}.elf",
"cwd": "${workspaceFolder}",
"MIMode": "gdb",
"miDebuggerPath": "${env:IDF_TOOLS_PATH}/tools/xtensa-esp32-elf-gdb/xtensa-esp32-elf-gdb",
"miDebuggerServerAddress": "localhost:3333",
"setupCommands": [
{"text": "target remote localhost:3333"},
{"text": "monitor reset halt"},
{"text": "monitor gdb_sync"},
{"text": "thb app_main", "ignoreFailures": true},
{"text": "set remote hardware-watchpoint-limit 2"},
{"text": "set remote hardware-breakpoint-limit 2"}
],
"customLaunchSetupCommands": [
{"text": "load", "description": "Flash target"},
{"text": "monitor reset halt", "description": "Reset and halt"}
],
"launchCompleteCommand": "exec-continue",
"serverStarted": "GDB\\ server\\ started",
"filterStderr": true,
"preLaunchTask": "idf: build"
}
]
}My project partner is working on putting the Black Magic firmware on a low-budget device to avoid the $75 device. When we get that going (within a week), I will be able try out your suggestion. Here is how I think it would be connected for my project:
VSCode/Cursor <----MI----> Proxy <---MI---> arm-none-eabi-gdb <---Serial---> Device running Black Magic firmware <---- wires ----> nRF52 SWDebug pins