Disabled breakpoints are erased from breakpoints list when sending a Breakpoint Request

[omarArm]

We are implementing a debug adapter extension. While implementing breakpoint features, we found out there is no distinction between enabling/disabling breakpoints and adding/removing them when they are being sent through a setBreakpointRequest. In other words, whenever a breakpoint is disabled, this breakpoint is removed from the breakpoint list being sent via the setBreakpointRequest.

This causes an inconsistency, between what is viewed in the Breakpoints Window in VS Code and what is happening in the backend.

To resolve this issue, we would probably need the stored breakpoint list to use some attribute in the breakpoint type when enabling/disabling it rather than adding/removing the breakpoint altogether.

[connor4312]

Disabling a breakpoint is a client feature and not represented in DAP. From a debugger point of view, a disabled breakpoint is the same as one that doesn't exist.

What's your use case for keeping disabled breakpoints around on the adapter side?

[omarArm]

The debugger we are using is GDB. In GDB and LLDB, breakpoints could either be disabled or deleted. In which case, a distinction is needed from the debug adapter's side to inform the debugger which mode is the user looking for.

I don't know if other debuggers do have a similar feature or not to be honest, but GDB and LLDB are both widely used debuggers.

[connor4312]

I am not a heavy gdb/lldb user, but from reading the docs it seems like their disabling vs enabling is also a "UI" feature within the TUI and I'm not clear on what benefit we'd get from propagating that through DAP.

What functionality or behavior would having a disabled metadata on breakpoint enable for your debug adapter?

[tromey]

In gdb, disabled is a state a breakpoint can have. It's a convenience for users -- like, I temporarily disable a breakpoint and then re-enable it later all the time. What's nice is it preserves the location and condition.

While the built-in gdb DAP implementation doesn't expose this feature, if a GUI exposes a command-line window and lets the users enter gdb commands there (i.e., evaluate request in the repl context), then a user could disable a DAP-supplied breakpoint, a state not representable in DAP. The interaction between these things isn't very well explored in general, IMO.

From a "pure DAP" point of view, though, enable/disable could be implemented purely on the client side.

[puremourning]

enable/disable is implemented client side. I don’t see a need for all servers to have to implement it.

[omarArm]

Hi @connor4312 , sorry for the late reply. So to give some background, we are using GDB for embedded system debugging. As to why it would be useful if the breakpoint status gets propagated through the adapter.

In GDB, each breakpoint has a unique ID that it gets when created, and no breakpoint can have the same ID even if the original one got deleted. For every GDB breakpoint there are a bunch of properties that are useful for a user to know. Examples include hit count and ignore count
When a breakpoint is disabled, all of these properties are retained for future viewing by the user. However, if it's deleted, then all of these valuable information just disappears.

Therefore, it is quite useful for the disable/enable state of a breakpoint to be propagated to the debugger via the adapter. This way it may become easier to integrate embedded debuggers with the VSCode environment