cdt-gdb-adapter
cdt-gdb-adapter copied to clipboard
[Feature Request]: Optional device reset during debug session
Problem
It is common for embedded debugger IDEs to have a reset button.
Such reset buttons often have configurable and/or device specific reset strategies. Normally, the device ends up at a reset vector, an application entry point, or at a main function after the reset operation completed.
Comparable built-in functionality in VS Code is the Restart Button. However, its default behavior is different from the above: it tears down and restarts all involved processes (including GDB and a GDB server for remote target debug) and reconnects to the target. Whereas the above reset functionality only resets the target/program execution.
The advantage of an "in-session" reset is that it's often easier to preserve error symptoms and register states. While a traditional VS Code restart may re-initialize parts of the system or download the application again. Also, depending on the debugger backend, this approach often has higher performance and isn't perceived as disruptive by end users as a full restart is.
It is important to keep the behavior of such a reset configurable. It often is very specific to an SoC's reset architecture.
Proposal
One option to deal with this is to provide a custom implementation of the restart request of the MSFT DAP protocol. But there are valid use cases for having a restart button with the standard VS Code behavior. And making the behavior configurable is tricky because debug adapter capabilities are announced with the initialize request. Which is before seeing the debug launch configuration coming in. Also, such resets can be very use case specific which IMO is an argument for having this in the launch configurations.
The probably better approach is to
- Add reset device functionality in addition to the default restart functionality.
- Add a launch configuration setting
resetDeviceCommands(name is negotiable). This is an array of GDB commands to execute when a reset device operation is requested. It's form is very similar to the existinginitCommandssetting. resetDeviceCommandsare executed as is. This can be for example a GDB server specificmonitorcommand for reset.- A GDB server needs to ensure that appropriate asynchronous GDB notifications are sent. Like
*runningwhen a reset starts and*stoppedwhen a reset completed AND the device is caught after reset. This gives the VS Code GUI a chance to refresh. - A new button gets contributed by
cdt-gdb-vscodeto the debug toolbar. This button is only visible if a launch configuration provides theresetDeviceCommandssetting. - All of this is probably less relevant for local GDB debug sessions. Hence, can be limited to the
gdbtargetdebugger type.
Note that we have started some prototyping around this to verify feasibility of the approach. We'd be more than happy to continue this work and open PRs here and at cdt-gdb-vscode (CC: @thorstendb-ARM).