Update Debug Adapter Protocol to support notifying of function breakpoints about debug-adapter-protocol

[colin-grant-work]

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]

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]

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]

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]

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.