cortex-debug VS debug-adapter-protocol

Cortex-Debug: VSCode debugger extension version 1.10.0 git(cf1c296). Usage info: https://github.com/Marus/cortex-debug#usage Reading symbols from arm-none-eabi-objdump --syms -C -h -w /home/smith/Documents/gpio_int_test/build/zephyr/zephyr.elf Reading symbols from arm-none-eabi-nm --defined-only -S -l -C -p /home/smith/Documents/gpio_int_test/build/zephyr/zephyr.elf Launching GDB: arm-none-eabi-gdb -q --interpreter=mi2 IMPORTANT: Set "showDevDebugOutput": "raw" in "launch.json" to see verbose GDB transactions here. Very helpful to debug issues or report problems Error: arm-none-eabi-nm failed! statics/global/functions may not be properly classified: Error: spawn arm-none-eabi-nm ENOENT Expecting `nm` next to `objdump`. If that is not the problem please report this. Error: objdump failed! statics/globals/functions may not be properly classified: Error: spawn arm-none-eabi-objdump ENOENT ENOENT means program not found. If that is not the issue, please report this problem.Launching gdb-server: /home/smith/openocd/src/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /home/smith/openocd/tcl -f /home/smith/.vscode/extensions/marus25.cortex-debug-1.10.0/support/openocd-helpers.tcl -f /interface/jlink.cfg -f /target/rp2040.cfg Please check TERMINAL tab (gdb-server) for output from /home/smith/openocd/src/openocd Finished reading symbols from objdump: Time: 11 ms Finished reading symbols from nm: Time: 9 ms Failed to launch OpenOCD GDB Server: Error: spawn /home/smith/openocd/src/openocd ENOENT

This guy: https://github.com/Marus/cortex-debug. Can grab it from the VSCode extensions window.

https://github.com/Marus/cortex-debug/issues/603 More info here.

There's also https://marketplace.visualstudio.com/items?itemName=maziac.asm-code-lens and https://github.com/Marus/cortex-debug

Thank you!

OK. I was thinking to assemble a "Press F5 to debug" solution to speed up my learning process. I'm used to command line tools and hacking stuff together too, so I should be fine if that is the state of the art for debugging (but it would be difficult to convince my coworkers in the future). I wonder if a combination of Eclipse for Rust and OpenOCD plugin is doable. Or perhaps cortex-debug[1] for VS:Code. I have some research to do, to explore the different solutions.

And I'm stuck on Windows too, since many of the tools I use require Windows.

Thanks again.

[1]: https://github.com/marus/cortex-debug

> There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.

The Language Server Protocol [1] is the best thing to happen to text editors. Any editor that speaks it gets IDE features. Now if only they'd adopt the Debug Adapter Protocol [2]...

[1] https://microsoft.github.io/language-server-protocol/

[2] https://microsoft.github.io/debug-adapter-protocol/

Wonder if they've got support for Debug Adapter Protocol? https://microsoft.github.io/debug-adapter-protocol/

> Debuggers need to do more things

It's true that coming up with an interface for an abstract debugger is harder, but it's not impossible. Microsoft create Debug Adapter Protocol (https://microsoft.github.io/debug-adapter-protocol/), which is conceptually similar for LSP. It's not perfect, but covers most basic operations pretty well, while leaving to the debugger to deal with the implementation details.

Most languages also include support for the Debug Adapter Protocol, and Haskell is no exception, so if you are so inclined, you can hook up your favorite editor/IDE and go to town.

They're working on the Debug Adapter Protocol but it doesn't have critical mass/adoption yet. And yeah, I end up having a fair share of dbg!(foo). It's not so bad since dbg!() also returns its value, so you don't have to mess with your code too much.

TL;DR: What would it take to implement a Debug Adapter Protocol (DAP)-based step debugger?

RDP is the Windows Remote Desktop Protocol that was in use for decades before VSCode; VSCode's own remoting doesn't use it.

I'd say that, in addition to LSP, the other big thing that came out of VSCode is DAP: https://microsoft.github.io/debug-adapter-protocol.

The most important part is the JDT Languag Server, it will give you the Java tooling for writing code. I think it has DAP support as well, so with a DAP client like nvim-dap you should be able to debug as well.