The Debug Adapter Protocol added BreakpointMode support in version 1.65 (via microsoft/debug-adapter-protocol#460), which introduced a mode property on SourceBreakpoint, InstructionBreakpoint, DataBreakpointInfoArguments, and ExceptionFilterOptions, along with a breakpointModes capability that adapters can advertise.
However, the VS Code extension API does not expose mode on any of the breakpoint classes. Currently SourceBreakpoint only accepts location, enabled, condition, hitCondition, and logMessage — there's no way to set or read the breakpoint mode through the public API.
This means there is no supported way for extensions to set breakpoint modes through the public API. As a workaround, we found that injecting the property directly via (breakpoint as any).mode = ... happens to work — the mode value does get serialized and passed correctly in DAP setBreakpoints requests to the adapter. But this is an undocumented hack relying on internal serialization behavior, not a public contract. It could break at any time without notice, and it comes with limitations:
- The mode is not reflected in the Breakpoints panel UI (users can't see which mode a breakpoint is set to)
- It bypasses TypeScript type checking, making it fragile and invisible to tooling
- It's not discoverable — extension authors have no way of knowing this works without inspecting VS Code internals
Proposal
Expose mode on the relevant breakpoint classes in the VS Code extension API, matching what DAP 1.65 defines:
SourceBreakpoint — add optional mode: string to constructor and as a readonly propertyFunctionBreakpoint — sameInstructionBreakpoint — same
Context
This was originally discussed in microsoft/debug-adapter-protocol#454, where the use case of hardware vs. software breakpoints in embedded/low-level debugging drove the DAP addition. The DAP side has been merged since February 2024, but the VS Code API hasn't caught up yet.
We're currently working on exposing this capability in eclipse-cdt-cloud/cdt-gdb-vscode#211 and are hitting this gap directly.
The Debug Adapter Protocol added
BreakpointModesupport in version 1.65 (via microsoft/debug-adapter-protocol#460), which introduced amodeproperty onSourceBreakpoint,InstructionBreakpoint,DataBreakpointInfoArguments, andExceptionFilterOptions, along with abreakpointModescapability that adapters can advertise.However, the VS Code extension API does not expose
modeon any of the breakpoint classes. CurrentlySourceBreakpointonly acceptslocation,enabled,condition,hitCondition, andlogMessage— there's no way to set or read the breakpoint mode through the public API.This means there is no supported way for extensions to set breakpoint modes through the public API. As a workaround, we found that injecting the property directly via
(breakpoint as any).mode = ...happens to work — the mode value does get serialized and passed correctly in DAPsetBreakpointsrequests to the adapter. But this is an undocumented hack relying on internal serialization behavior, not a public contract. It could break at any time without notice, and it comes with limitations:Proposal
Expose
modeon the relevant breakpoint classes in the VS Code extension API, matching what DAP 1.65 defines:SourceBreakpoint— add optionalmode: stringto constructor and as a readonly propertyFunctionBreakpoint— sameInstructionBreakpoint— sameContext
This was originally discussed in microsoft/debug-adapter-protocol#454, where the use case of hardware vs. software breakpoints in embedded/low-level debugging drove the DAP addition. The DAP side has been merged since February 2024, but the VS Code API hasn't caught up yet.
We're currently working on exposing this capability in eclipse-cdt-cloud/cdt-gdb-vscode#211 and are hitting this gap directly.