Can't insert break points without pause

[mttbx]

When I insert bp without pause, the output is:
"Cannot execute this command while the target is running.\nUse the "interrupt" command to stop the target\nand then try again."

[mttbx]

I found in "cortex debug", they do these things automatically:
exec-interrupt
break-insert
exec-continue

[GitMensch]

A bit of checking in the code showed that this is done conditionally there:

            if (this.stopped) { await createBreakpoints(false); }
            else {
                this.disableSendStoppedEvents = true;
                this.miDebugger.once('generic-stopped', () => { createBreakpoints(true); });
                this.miDebugger.sendCommand('exec-interrupt');
            }

To integrated the same change we have to add the stopped attribute first which is a bit more work, but as the code is MIT-licensed I think it can be integrated (aka "copied") here. @WebFreak001 What do you think about those two?

[WebFreak001]

we can't really take code from them as their license is less permissive than the one used here (public domain)

but the idea for it is quite simple and should be fairly straightforward to implement anyway

[GitMensch]

The Termdebug extension in Vim uses the same approach (check if currently stopped, if not interrupt before and continue after setting the breakpoint). @WebFreak001 - As you've mentioned that should be easy to add, do you plan to do so soon?

[WebFreak001]

I'm still here for small fixes and occasional maintenance, but I'm not really working on this extension much anymore, so I don't have an ETA.

@GitMensch you regularly post here, would you like to be added as collaborator for this repository to manage PRs and issues?

[GitMensch]

@WebFreak001 I'm honored and if you feel I'd fit that role: yes please add me. In any case can you please try to have a look at this one? It seems you are very near to the solution already.

[GitMensch]

Stopping and continuing automatically always has one issue: if you are currently working under "run till here" or "finish" in a long running function, then the auto stop+continue will lead to the debugger running more than "till here" / more than "finish this function".
A possible way to resolve that would be to explicit document "this will happen, consider it when clicking somewhere in the UI"; or "remember" the last "go to state" (we may be able to read this from the GDB output, not sure; we do know this if the command was sent by the user via UI; we are unlikely to get that correct from checking the GDB console input [can also happen with self-defined commands, with a different set of abbreviations and aliases, ...]).

A third approach was noted by @infn-ke:

or should added/removed breakpoints be reconciled between UI and gdb when target is stopped?

That could be a reliable way without side effects (if we don't drop every breakpoint and re-create this again - that would be bad because of attached/active "skip"/"commands"/"condition"/...).