Allow to set data breakpoints

[haydar-metin]

What it does

Allows to set data breakpoints within the memory table.

Closes #102

Peek.2024-05-30.12-16.mp4

Breakpoints set externally will have a dashed outline, internal breakpoints will be solid.

Extension API

The VSCode extension API does not support creating Data Breakpoints directly through their API. The method extHostDebugService.ts#addBreakpoints currently lacks the ability to forward data breakpoints (i.e., missing DTOs), while MainThreadDebugService.ts#$registerBreakpoints already supports it. However, we only have access to the extension API which uses the extHostDebugService internally. That means, we don't have a way to tell VSCode to show new Data Breakpoints within their UI! Consequently, we need to manually track our breakpoints (for now).

microsoft/vscode#195151

Debugger / Logs

Unfortunately, the debugger does not return the hitpoints on a stop event (it is not set). For that reason, to see the inline breakpoint marker, you need to set the data breakpoint through VSCode. For the prototype, all data breakpoints set from the outside will be assumed to be always hit for demonstration purposes.

The logs and workarounds for showcasing the prototype will be removed before merging.

https://microsoft.github.io/debug-adapter-protocol/specification

How to test

1. Start the debugger
2. Open the memory inspector
3. Set data-breakpoints through the context menu for variables and groups.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the contribution guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the code of conduct

[colin-grant-work]

I haven't looked at the code in detail, but I'm a little confused about the 'internal' vs. 'external' data breakpoint accounting. It looks like 'internal' breakpoints are those set through the Memory Inspector UI while 'external' are set by other means, but I'm not sure that that that should really matter. Are there differences in what the user can / should do with the two types?

[colin-grant-work]

A bit suspicious that the breakpoint service stands alone here. Can its functionality be broken down into more composable parts?

[haydar-metin]

I haven't looked at the code in detail, but I'm a little confused about the 'internal' vs. 'external' data breakpoint accounting. It looks like 'internal' breakpoints are those set through the Memory Inspector UI while 'external' are set by other means, but I'm not sure that that that should really matter. Are there differences in what the user can / should do with the two types?

@colin-grant-work You are absolutely right. However, due to the problem with not being able to set data breakpoints in the VS Code extension API, this was a way to overcame it.

We have the following situation right now:
The user can set new data breakpoints within the debugger UI (VSCode). Setting those will trigger a SetDataBreakpoints request with the local data VSCode itself has. That means, it will override our own data breakpoints we have set as we can not tell VSCode about those (See PR description - the API does not allow to forward any data breakpoints to the debugger UI).

For this reason, the current solution tracks all data breakpoints and splits them into external and internal (internal => MemoryInspector). Now, if someone sets from the outside a new data breakpoint, then our internal breakpoints will be appended to the request, so that our internal breakpoints will be still active.

If you can recommend a better/stable approach I would be glad to implement it to overcome the API issue.

[colin-grant-work]

I agree with the problem statement, but I think the details don't need to leak as widely as they currently do: we're strictly more knowledgeable / powerful than the VSCode UI, because we know about their breakpoints, but they don't know about our breakpoints.

This has two consequences:

• Breakpoints we create won't show up in their GUI
• Breakpoints they create and we delete (if we allow deletion of their breakpoints) won't disappear from their GUI

That is, both internal and external breakpoints have certain disabilities, and either way, we basically have to tell users to trust us and not trust the VSCode GUI. As long as that's true, I'm not sure it makes sense to make the distinction pervasive: in my view, only the service that handles reconciliation really needs to know which is which.

But it also suggests a further enhancement: a data breakpoints tree contributed to the debug view. There, we could show what we know to be the full set of current data breakpoints so that users have an authoritative record in the debug view as well as in our views. We still have the problem that if users use the VSCode builtin commands from the variable view, then their GUI will know about the breakpoint but not any others, but we also have our record right next to theirs.

[jreineckearm]

First of all, thanks a lot @haydar-metin for this PR! This is awesome work and I like the out-of-the-box thinking to overcome the data breakpoint gap in the VS Code API.

This is going to be a powerful feature once we get a handle on the disconnect to the VS Code breakpoint view.
I agree that the internal vs external terminology could be a bit misleading. But probably a minor issue.

What's worrying me more in the meanwhile is the disconnect between custom data breakpoints and VS Code.
This can make things tricky when you work with data breakpoints that require HW debug logic with limited resource. Which is why we'd need a central view showing all data breakpoints of a session.

However, I'd advise against creating a new view for that. We need to ensure this integrates with the existing centralized breakpoint view. Otherwise, this gets difficult to manage for users.

I've played around with a couple of things, but neither found a good way yet without fixing this in VS Code:

• No good way to update the DTOs/breakpoint view. Made worse by the fact that I can't see a way to list all installed breakpoints via MS-DAP. Which would allow refreshing the view in VS Code based on what's really going on the debugger.
• No way of injecting custom breakpoint events from outside the debugger to update the breakpoint list. Or I missed it on the session API.

I'll keep on thinking about other ways to achieve that sync. But we may also want to consider creating a PR on VS Code. If I understand correctly, an issue exists already there.

[colin-grant-work]

No good way to update the DTOs/breakpoint view. Made worse by the fact that I can't see a way to list all installed breakpoints via MS-DAP. Which would allow refreshing the view in VS Code based on what's really going on the debugger.

I think that this might be the easiest way to attack the problem from a VSCode standpoint. I think that data breakpoints have languished a bit because they've backed themselves into a corner: other breakpoints can be added without reference to a session and then sent to any session, but the way data breakpoints have been implemented, they're at least partly bound to a session. That means that they can't really treat data breakpoints the same in the plugin API - I once started down the naive path and then realized that expectations differ quite a bit - and that means that they'd have to implement entirely new API for data breakpoints. It wouldn't really be that bad - either an addDataBreakpoint method on a DebugSession or a variant of vscode.debugaddBreakpoinst that accepts a session would work, for example - but since it isn't entirely parallel to the other two breakpoint kinds, it's likely to require a fair bit of discussion and time. On the other hand, some way for the protocol to fetch breakpoints in addition to setting breakpoints might be more straightforward, or an extension of the breakpoint event to allow it to handle more cases, might face less resistance.

[jreineckearm]

Thanks a lot, @colin-grant-work , for sharing your findings from previous investigations! This is really useful!
Particularly the fact that there currently is no session-awareness for other breakpoint types is an interesting one....

[planger]

We certainly recognize the issue with not being able to display data breakpoints consistently to the user due to the current limitations in the VS Code API. For UX reasons, we would prefer not to introduce a separate view just to manage data breakpoints.

Therefore, we've opened a PR in VS Code that extends the vscode.debug API to allow users to manage data breakpoints and display them in the standard breakpoint view. This should resolve the inconsistency issue once it’s merged.

Given that this PR is in progress and hopefully will be merged soon, can we proceed with merging this PR, or are there any objections or additional considerations we should address beforehand? @colin-grant-work @jreineckearm

Thank you!

[colin-grant-work]

Given that this PR is in progress and hopefully will be merged soon, can we proceed with merging this PR.

If the idea is that this PR should use the new API when available, it would seem odd to me to proceed with it before that API is available.

[planger]

@colin-grant-work Right, the idea was that we already include the data breakpoint feature already now, as it already adds value, and solve the remaining UX deficiency by adding data breakpoints in the VS Code breakpoint view, once the new VS Code API is available.

[planger]

Oh, as I just realized (thanks for the hint @haydar-metin), we need to revert ad8062a to enable the functionality before merging (before or after the VS Code API is available).

[colin-grant-work]

@colin-grant-work Right, the idea was that we already include the data breakpoint feature already now, as it already adds value, and solve the remaining UX deficiency by adding data breakpoints in the VS Code breakpoint view, once the new VS Code API is available.

@planger, yes I understand, but if we were holding up this PR because of the deficiencies in the current API, then I don't understand why we would proceed before those deficiencies have been remedied. Nothing has changed yet from the time that we decided not to proceed with this approach because of its UX problems imposed by the VSCode API.

[planger]

I understand your concern! I was just thinking, this PR already adds value as is and the UX deficiency may not be that big of an issue, if you are aware that data breakpoints don't show up in the VS Code breakpoint list. But you are right, we need to weigh the value it adds against the confusion it may entail.

[colin-grant-work]

I'm open to an argument that we should proceed, and perhaps should have proceeded, but the fact that the API may be improved in the future doesn't directly bear on that question: we would need to decide whether we believe that the value it provides now outweighs the concerns about UX that led to our pausing in the first place.

[jreineckearm]

I'd like to revive this discussion since it went stale for a while.

Unfortunately, the PR microsoft/vscode#226735 hasn't seen much attention after answering and implementing requested changes. Yet I believe the added value with this PR as it is could help users already. Even if it's not necessarily production quality without the VS Code change.

Also, I am still a bit reluctant to add complexity for users by adding another breakpoint management dialog for the "internal" breakpoints.

I am wondering if we could go with a compromise and add an experimental feature flag to the extension settings (only there, no need to have it in the view settings dialog). Users would need to opt in to get access to more yet still pre-release quality functionality.
Apparently it would need README updates to highlight what's possible. But we might get a chance to get real user feedback on how badly the functionality needs improvements (and maybe more workarounds like the custom breakpoint dialog). Or just learn we would spend too much time on a feature no one cares about.

@planger , @haydar-metin , @colin-grant-work , what do you think about such approach?
@haydar-metin , how much effort would you see in making the feature only visible base don such a experimental feature setting?

[colin-grant-work]

I am wondering if we could go with a compromise and add an experimental feature flag to the extension settings (only there, no need to have it in the view settings dialog). Users would need to opt in to get access to more yet still pre-release quality functionality.

I think this is a fair compromise, as it gives us a chance to advise users about what to expect before they opt in.

CC: @WyoTwT, for Ericsson's view, if you have a strong opinion.

[haydar-metin]

The the latest changes now introduces:

• Experimental flag to toggle this functionality
• Contribution Services for the VS Code context menu and class names
• Way to inspect existing internal breakpoints (similar to how the command Developer: Inspect Context Keys works)
• Show an error message when the debugger fails to set a breakpoint

PS: The isHit functionality does not work for the Arm Debugger, as it doesn't return the reason why the debugger stopped, e.g., breakpoint.

[jreineckearm]

Some comments from code review. Not tested yet.

[jreineckearm]

Few more comments from testing. Behavior looks mostly consistent.
There is some room for enhancements (see issues for a separate PR section). But we should aim for getting this PR over the line for someone else to pick up such improvements in future.

To consider now:

• I don't understand the "inspect existing internal breakpoints" command. Nothing seems to happen. The other command you mention gives me a different mouse pointer style and highlights things when hovering over them.
• I still see "Memory: Inspect Breakpoints" and "Memory: Remove All Internal Breakpoints" in the "recently used" list if I turn the experimental feature flag off and open the command palette. Probably not much we can do.

To be aware of in case questions come:

• You should better disconnect/reconnect the debugger and power-cycle the board if you change the experimental setting. GUI support goes away. But data breakpoints remain installed in target system.

Some could become improvements in a separate PR.

• Might want to turn the frame of a selected group red even if selected.
  
• Horizontally align breakpoint icon and address value text.
• A tooltip when hovering over the breakpoint icon with more info about the set data break.
• I get all breakpoint options even if a breakpoint is already set.
• We may need a "restore data breakpoints" setting if that is not available already on VS Code level. If you accidentally set a break that gets triggered at a bad time during device boot, it may lock you out until you use a clean project without breakpoints to restore.
• Could consider a "remove breakpoints on row" command. But let's not overdo it now.

[haydar-metin]

@jreineckearm

I don't understand the "inspect existing internal breakpoints" command. Nothing seems to happen. The other command you mention gives me a different mouse pointer style and highlights things when hovering over them.

Both commands provide an output to the console. The VS Code command outputs all context keys after clicking somewhere.

I still see "Memory: Inspect Breakpoints" and "Memory: Remove All Internal Breakpoints" in the "recently used" list if I turn the experimental feature flag off and open the command palette. Probably not much we can do.

Fixed

You should better disconnect/reconnect the debugger and power-cycle the board if you change the experimental setting. GUI support goes away. But data breakpoints remain installed in target system.

All internal breakpoints are now removed on disable.

Might want to turn the frame of a selected group red even if selected.

Done

Horizontally align breakpoint icon and address value text.

Done (vertically)

I get all breakpoint options even if a breakpoint is already set.

It is also the default behavior of VS Code if you create a breakpoint through the Variables view. Should we do it differently?

[jreineckearm]

Both commands provide an output to the console. The VS Code command outputs all context keys after clicking somewhere.

Ah, finally got it. Missed the part that it logs to console.log().
Should we rather log into the Memory Inspector Output log channel? You could for example use outputChannelLogger.info . And maybe tie visibility of the option to the currently selected verbosity level extension setting?

I still see "Memory: Inspect Breakpoints" and "Memory: Remove All Internal Breakpoints" in the "recently used" list if I turn the experimental feature flag off and open the command palette. Probably not much we can do.

Fixed

Can confirm.

You should better disconnect/reconnect the debugger and power-cycle the board if you change the experimental setting. GUI support goes away. But data breakpoints remain installed in target system.

All internal breakpoints are now removed on disable.

Awesome, thanks.

Might want to turn the frame of a selected group red even if selected.

Done

Great, thanks.

Horizontally align breakpoint icon and address value text.

Done (vertically)

Was a 50/50 chance....but yeah, that's what I meant. ;-)

I get all breakpoint options even if a breakpoint is already set.

It is also the default behavior of VS Code if you create a breakpoint through the Variables view. Should we do it differently?

Got you. No, lets stay with how VS Code works.

One other thing related to the discussion with @colin-grant-work earlier about internal and external breakpoints:
I have to admit that as a user, the term internal breakpoint is probably meaningless to me.
I'd be fine with leaving the name in the source code until we have support in the VS Code API (I saw some movement started again in microsoft/vscode#226735). But maybe we can change the command name Remove All Internal Breakpoints to something like Remove All Memory Inspector Breakpoints. Or to keep it slightly shorter Remove All Memory Breakpoints. Memory breakpoints aren't really a thing yet in DAP or VS Code. So, might not be easily confused.

[jreineckearm]

I tested the changes and would be fine with merging the experimental functionality. Turning it on and off feels like a consistent experience now. Maybe just address the last two comments (logging and "remove all" name).

Happy to address documentation updates separately before the next release.

@colin-grant-work , do you see anything else that must change before we can merge this PR?
@WyoTwT , anything from your side?

I am planning to merge this latest on Monday afternoon (CET) unless strong objections or strong change requests come in that can't be handled separately by follow-up issues.

[colin-grant-work]

Remove All Memory Inspector Breakpoints

I like this suggestion, I think. Since we're operating in a zone of fairly obscure distinctions, I do think it's important to try to be as clear and transparent with user-facing language as possible for both ease of use and education on the functionality.

[WyoTwT]

I tested the changes and would be fine with merging the experimental functionality. Turning it on and off feels like a consistent experience now. Maybe just address the last two comments (logging and "remove all" name).

Happy to address documentation updates separately before the next release.

@colin-grant-work , do you see anything else that must change before we can merge this PR? @WyoTwT , anything from your side?

I am planning to merge this latest on Monday afternoon (CET) unless strong objections or strong change requests come in that can't be handled separately by follow-up issues.

Sorry for the late response. Nothing from my side.

[haydar-metin]

• Renamed Remove All command to use Memory Inspector instead of Internal.
• Output is logged to the output channel and only possible if the verbosity is set to either info or debug

[jreineckearm]

Thanks for the final touches and all the hard work on this one! :-)

Now looking forward to the API changes finding their way into VS Code to fully complete this feature.

Good to go as far as I am concerned. But will wait with merge until Monday as announced earlier.

[jreineckearm]

Merging now as no further feedback came in.

[noneghost]

hi，Does this feature require an update to the VS Code API to be usable, and will it function properly in future Theia versions?

[colin-grant-work]

@noneghost, as implemented here, this interacts directly with the debug adapter and skips registering breakpoints with the VSCode API, as that is currently impossible, pending microsoft/vscode#226735. Therefore, this approach should work without a VSCode API update. A future version of this plugin may update to a version of the VSCode API that includes the functionality from microsoft/vscode#226735. Such an update should be reflected in the package.json's engines field, enabling users of the plugin to ensure that they match their plugin version to their VSCode API version. Theia aims to support the latest VSCode API, and so this plugin should continue to work in Theia after such an update, although there might be a lag of a version or two, depending on the speed with which the new API is added to Theia.

[noneghost]

@noneghost, as implemented here, this interacts directly with the debug adapter and skips registering breakpoints with the VSCode API, as that is currently impossible, pending microsoft/vscode#226735. Therefore, this approach should work without a VSCode API update. A future version of this plugin may update to a version of the VSCode API that includes the functionality from microsoft/vscode#226735. Such an update should be reflected in the package.json's engines field, enabling users of the plugin to ensure that they match their plugin version to their VSCode API version. Theia aims to support the latest VSCode API, and so this plugin should continue to work in Theia after such an update, although there might be a lag of a version or two, depending on the speed with which the new API is added to Theia.

Thanks for your feedback