How does the debugger notify dap client that a breakpoint is disabled?

[demin-han]

for example, using gdb in vscode:

1. add breakpoint in editor
2. use debug console to disable this breakpoint
3. the breakpoint's status in UI is not changed

I haven't found the enable or disable field in Breakpoint type.

[connor4312]

There's no "disabled" state in DAP. In VS Code, a disabled breakpoint is simply not sent to the debugger.

[demin-han]

There's no "disabled" state in DAP. In VS Code, a disabled breakpoint is simply not sent to the debugger.

it is OK from editor to debugger. what about from debugger to editor? if I disabled breakpoints through debug console, the breakpoint's status would be inconsistent. In debugger side, the breakpoint is disabled, but in VS Code side, the breakpoint is still enabled. The breakpoint changed event seems not work for this, because of no "disabled" state in breakpoint response.

[connor4312]

That's correct, the debug adapter does not control the breakpoint enablement state. If it fails to set a breakpoint, it can signal that by marking it as unverified with a message. But the adapter is driven by the client, not the other way around.

Is there a use case you have in mind where having the DA disable a breakpoint would be useful?

[demin-han]

As I know the unverified status is for pending. I think it's a common case(or debug workflow) for users who like use debug console.

Could this be improved in future dap version? 1 Add "disabled" field or 2 Reuse "reason" field ?

[connor4312]

That sounds like something that clients should implement in their "debug console"s rather than in DAP.

[demin-han]

when I input CMD in debug console, it's a "evaluate" REQ, I think the client don't understand these CMD. Current breakpoint definition of DAP can't tell or distinguish the disable of breakpoint , the client receives the change event, but don't know the reason which is breakpoint disable.

[connor4312]

That is up to the client. There's no requirement in the protocol that a debug console exists or how it should behave.

There is no notion of disabled breakpoints in DAP. And I would not implement it the way you describe e.g. in VS Code, because it would not play nice if there were multiple concurrent debug sessions happening at the same time: a UI breakpoint is not owned by a debug adapter.

It sounds like the way to do what you want would just be to set verified: false with some message like "Disabled by the user" or something along those lines.

[demin-han]

It sounds like the way to do what you want would just be to set verified: false with some message like "Disabled by the user" or something along those lines.

Yes, something like this. Currently, just set "verified: false" the checkbox is still checked in VS code UI. The "verified" field is set just according to breakpoint pending status for several gdb adapter . If the "message" or "reason" field are not defined formally, how different dap clients to parse the meaning of message ?

/**

• A message about the state of the breakpoint.
• This is shown to the user and can be used to explain why a breakpoint could

• not be verified. */ message?: string;

  /**

• A machine-readable explanation of why a breakpoint may not be verified. If
• a breakpoint is verified or a specific reason is not known, the adapter
• should omit this property. Possible values include:
• • pending: Indicates a breakpoint might be verified in the future, but
• the adapter cannot verify it in the current state.
• • failed: Indicates a breakpoint was not able to be verified, and the
• adapter does not believe it can be verified without intervention.
• Values: 'pending', 'failed' */ reason?: 'pending' | 'failed';