Problem setting breakpoints in vscode when target is running

[jprui]

• gdb version is 8.0. same for gdbserver
• extension version is 0.26.0
• gdb does not allow setting breakpoints while the target is running but the extension should do an interrupt, plant the breakpoint, and then continue

This seems similar to #292 but it doesn't seem like anything was ever done to allow vscode to plant breakpoints while the target is running.

If I try to plant a breakpoint while the target is running, there is a pop-up message saying:

Cannot execute this command while the target is running.
Use the "interrupt" command to stop the target and then try again. (from break-insert -f "/export/space/jpruitt/soc_camera_sw/ARM/camera_software/src/main.cpp:18")

After getting this message the breakpoint is not planted but it is listed in the breakpoints window and the source line gets a dot so vscode thinks the breakpoint is planted but it is not.

To avoid this inconsistency, the extension should either stop the target, set the breakpoint, continue the target or it should indicate to vscode that the breakpoint could not be planted.

A similar situation arises if you try to "Stop Debugging" while the target is running. In vscode, it thinks it has stopped debugging, but gdbserver is still running and it is in a weird state. If you do "Stop Debugging" when the target is not running, then vscode exits cleanly and so does gdbserver.

It is a royal pain to have to remember to manually stop the target before changing the state of the breakpoints or to stop debugging. Other debuggers like QtCreator can work with gdbserver and give the illusion that it can plant breakpoints while the target is running and it undoubtedly does a stop and continue behind the scenes since the gdbserver does not directly support setting breakpoints while the target is running.

Thanks.

launch.json

{
    "configurations": [
     {
        "type": "gdb",
        "request": "attach",
        "name": "Attach to gdbserver",
        "executable": "ARM/camera_software/.libs/camera_application",
        "target": "localhost:10000",
        "stopAtEntry": true,
        "remote": true,
        "cwd": "${workspaceRoot}", 
        "valuesFormatting": "prettyPrinters",
        "gdbpath": "/opt/poky/2.4.3/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb"
    }]
}

In my configuration, the localhost port of 10000 is actually an SSH tunnel from a linux system to a PC which forwards it to the actual target that is local to that PC. The vscode is running on the linux system and seems to have no problem connecting and debugging except for this inability to set breakpoints while the target is running.

[GitMensch]

The referenced issue was about setting breakpoints at all, especially on connect, which was solved by adjusting the order of the connection and the optional, configurable "break at start".

In theory this extension could:

• watch connected state (note: this is only a "near" solution, as the inferior may be stopped/running until we get the asynchronous note)
• store the interaction token for setting breakpoints and if we get the note about "not able to set" then send an interrupt, then set the breakpoint again and a continue (note: this will break the "go until" / "advance" ad the "exit function" feature, so we only change a "often not possible" to "sometimes broken")
• make the function that set breakpoints wait for the answer and either tell the UI "did work" or "did not work" (may slow down a bit, but seems most clean)