search

microsoft / debug-adapter-protocol

Defines a common protocol for debug adapters.
https://microsoft.github.io/debug-adapter-protocol/
Other
1.44k stars 131 forks source link

Update Debug Adapter Protocol to support notifying of function breakpoints #8

Open davidcummingsaapl opened 6 years ago

davidcummingsaapl commented 6 years ago

Raised as a result of the suggestion from @weinand on https://github.com/Microsoft/vscode/issues/59746

The debug protocol provided by vscode allows the IDE to inform the debug server of function breakpoints that should be set by sending a SetFunctionBreakpoints request. This request contains an array of objects of type FunctionBreakpoint.

The debug protocol also allows the debug server to inform the IDE that breakpoints have been set by sending a BreakpointEvent. This event contains information on whether the breakpoint was added, removed or changed and contains an object of type Breakpoint representing the event.

Unfortunately this Breakpoint type is for source breakpoints and doesn't contain the ability to specify information about function breakpoints. I tried a few different things by not setting line numbers, source file etc. but they all resulted in issues with the breakpoints view in vscode.

I had a look through debugSession.ts in the vscode source (see line 365) and there is some logic for function breakpoints, but it doesn't apply if the reason on the event is 'new'

colin-grant-work commented 1 year ago

I believe this would be a very desirable enhancement. It does not seem very logical to allow a different set of breakpoint types to be created from the frontend than those whose creation can be sent as an event from the adapter.

puremourning commented 1 year ago

the response to setFunctionBreakpoints is an array of Breakpoints, not an array of "function breakpoints". i.e. the server always tells the client explicit source/ine for the "resolved" breakpoints.

I think the point is that the DA resolves the function bp into a line bp as that's what it will actually break on (typically?), no? and the client can then render a marker on the source line where the 'Function' breakpoint resolved to.

colin-grant-work commented 1 year ago

How the debugger or the adapter resolves a breakpoint is entirely an internal matter, and it's certainly not the case that every breakpoint will always be resolved to a source breakpoint. For one thing, it's possible to debug a binary for which no source information is available. And if symbol information is available but not source information, then it might be possible to set a breakpoint that can be resolved as an instruction breakpoint but can't be resolved as a source breakpoint at all. If everything could really be reduced to a source breakpoint, then there wouldn't be any point in adding the other breakpoint varieties to the protocol at all - we could just always expect users to find the right place in source to put one. More realistically, all breakpoints boil down to instruction breakpoints, but we certainly wouldn't want to make users input them as such, and we wouldn't want to present them as such, either.

Beyond the theoretical issue, there's also an issue of presentation. Suppose a function breakpoint is added by a user in the debugger directly (by typing in a GDB terminal, say). Since function breakpoints are supported by GDB natively, the user would expect to see a function breakpoint in the UI, but the current protocol forces the adapter to transform it in the breakpoint event, creating a mismatch on a quite practical level, even if the source can be resolved.

puremourning commented 1 year ago

Sure, my point was that the response to setFunctionBreakpoints may need to change, in the sense that it might be a simpler API change to add metadata to the Breakpoint object.

colin-grant-work commented 1 year ago

Yes, I agree with that. I think it's odd that the breakpoint variants don't extend a core Breakpoint interface, but are just declared separately - it's backed the protocol into a corner on this point, a bit.