Support resetting the target via GDB's `monitor [COMMAND]` command

[navnavnav]

GDB users can send special (custom) commands to the server via the monitor command. Some GDB servers used for embedded debugging support the custom reset command, which triggers a target reset. Users can invoke this by running monitor reset in GDB.

It would be nice if Bloom supported the following custom commands:

• reset - To reset the target and let it run.
• reset halt - To reset the target and hold it in a stopped state.

I plan to include this work as part of the refactor of the GDB server implementation.

[navnavnav]

I've been unable to find a way to tell GDB that target execution has resumed. There doesn't seem to be any packet we can send, in response to the qRcmd command packet, to tell GDB that we've resumed execution on the target.

This means we cannot offer users the ability to reset the target and let it run, with a single command. But I don't think this is much of a problem, as the user can just run the continue command right after the reset command:

> monitor reset halt
> continue

For this reason, I don't think there's any need for the halt in the reset command. There will just be one command that triggers a reset and holds the target in a stopped state.

Should be done with this soon.

[maximevince]

IIRC, on ARM targets:

• monitor reset will reset the board, and continue execution right away. Indeed, GDB is not "in sync" with the running state, but you can just type c / continue manually and you're back "in sync".
• monitor reset halt will reset the board and keep it halted, requiring the user to manually hit continue before the target is running again.

I do see a use for monitor reset without halt, since that allows you to reset the board from the debugger, then exit gdb without halting the target.

[navnavnav]

Ah, that's interesting @maximevince. I wasn't aware other GDB servers would do that.

I do see a use for monitor reset without halt, since that allows you to reset the board from the debugger, then exit gdb without halting the target.

I believe Bloom already does this for you. Ending the GDB debug session whilst the target is halted will result in Bloom resuming target execution. And if Bloom is configured to release the debug tool at the end of a debug session, then this will always mean resuming target execution (as detaching from the target will put it back into a running state).

[maximevince]

Is there a way to reset and halt the target now? Can it be done through the Insight UI?

[navnavnav]

Hi @maximevince

Development for this is mostly complete but it's not yet ready for release. There are some parts of the target resetting implementation that need some tidying. The changes are in the develop branch, for version 0.9.0, but it will be a while before I publish that release. I have a lot more work to do before that release.

In the meantime, you could simply restart the debug session to trigger a target reset. It's not the nicest solution, but should work for the short-term. Bloom will automatically reset the target at the beginning of a new debug session, so killing the session (in GDB) and starting a new one should be enough.

Do you use an IDE? CLion provides a function to reset the target, and it works by doing exactly as described above - it simply ends the GDB remote debug session and starts a new one.

If you do go with the above approach, you may want to set releasePostDebugSession to false, in your debugTool config. This way, Bloom won't have to disconnect from the target and debug tool on each reset.

I will let you know when I have a better idea for when 0.9.0 will be published.

[navnavnav]

Development for this is complete. The changes are in the develop branch. They will be shipped with v0.9.0. See the associated milestone for updates (https://github.com/navnavnav/Bloom/milestone/4).