Possibility to add data breakpoints

[britalmeida]

Please add a feature to "Add data breakpoint" (at least?) for the C and C++ language.

Ideally, this would be available both by:

• entering an address or variable name in the breakpoints panel, and
• right-click a variable within the code and "Add data breakpoint".

[weinand]

We will start exploring this in November

[weinand]

corresponding DAP proposal: microsoft/debug-adapter-protocol#20

[weinand]

What we plan to do:

• we support a new breakpoint type "data" which will be shown in the breakpoints view with a new icon
• a data breakpoint can be created via a context menu action in the Variables and Watches view
• data breakpoints have condition, hit count, and logPoints attributes (and the implementation provides information about what attributes are supported).
• hitting a data breakpoint stops the program and the reason is shown in the Stacktrace.
• initially a data breakpoint is defined by an expression and as such has no source location (in this respect it is similar to a function breakpoint). In the future it might become possible to set data breakpoints directly in the source and to show them in the gutter.

[britalmeida]

The plan sounds great!

Regarding the UX:

• it would be nice to be able to add a data breakpoint for a variable, also by right-clicking it on the source code directly. Otherwise, there is an extra step of having to add the variable to the Watches first.
• it would also be nice to be able to enter an address manually, instead of just a variable name. This action is usually available on the breakpoints panel.
• I can't immediately see a case where it would be helpful to see data breakpoints in the gutter. I would expect to see breaks for the flow there, but a data breakpoint would potentially show in many places. A common case of setting a data breakpoint is because it is not known when/where the data is changing, or it may be getting trampled by something else.

Data breakpoints with a condition, hit count and log:

• this sounds super powerful! I can already see the use of checking when a variable is cleared or set to a specific value ^^
• mind that logpoints are currently not working in C++ -> Conditional breakpoints and log points cause execution to stop as if it were a normal breakpoint. vscode-cpptools#2862

[weinand]

@britalmeida thanks for the feedback.

• if you read my proposal carefully, you will find that I already mention "setting data breakpoints directly".
• VS Code will never deal with "addresses". It only sends strings to the backend and the backend can decide what to do with it.
• VS Code provides the UI, but not the implementation in the backend. So the conditions, hit counts and log points are only powerful, if a debugger extension is able to implement them. So please don't hold your breath...

[smorin-primero]

I wanted to add a link to #55931, because it's been marked as closed, but essentially, it is talking about the same thing.

[fredijude]

@weinand : will 'Data Breakpoint' will be part of the February 2019 VS Code release ? If not, when is it planned for ?

[weinand]

The VS Code UI for Data Breakpoints is planned for March or April. But don't hold your breath...
In addition debugger extensions will have to provide backend support for Data Breakpoints.
We don't know when this will happen.

[weinand]

What we plan to do in August:

We support a new breakpoint type "data" which will be shown in the breakpoints view with a new icon (tbd). Data breakpoints optionally have a condition, a hit count, and support logPoints but currently VS Code has no UI to edit these attributes outside the source editor.

In the initial implementation data breakpoints only exist while a debug session is active (which means that data breakpoints are not persisted across debug sessions).

Only if a DA has a supportsDataBreakpoints capability, will VS Code use the data breakpoint specific DAP requests.

A data breakpoint can be created via a context menu action in the Variable view. The variable's reference and name is passed to the DAP request dataBreakpointInfo to determine whether the variable supports a data breakpoint. If successful the response provides an ID, a UI, and a set of access types for the data breakpoint. Also returned is a canPersist attribute that we will ignore in the initial implementation. The data breakpoint is shown in the breakpoints view with its UI name. We have to decide what to do with the access types. For the initial implementation I suggest that we just support the write access type (since that's the most useful anyways).

Data breakpoints are registered with the DA via the setDataBreakpoints request (which works similar to the setFunctionBreakpoints request).

Hitting a data breakpoint stops the program and a reason "data breakpoint" is shown in the Stacktrace view and the data breakpoint's name is shown when in the hover. Ideally we could show this information in the source as well (like we do for exceptions). Here is what VS shows in this situation:

Additional Info:
The DAP spec can be found here: microsoft/debug-adapter-protocol#20

[weinand]

@isidorn I've created a mock implementation of data breakpoints in a branch of vscode-mock-debug: https://github.com/microsoft/vscode-mock-debug/tree/aweinand/databreakpoints

[isidorn]

Thanks a lot. I'll pick this up and add UI.

[isidorn]

I pushed an initial version of data breakpoints via a7cc79a
Initialy this seems to work fine for me with the Mock Debug.

This still needs quite some testing. So on Monday I plan to verify:

1. That the enablement/disablement state gets respected
2. Data breakpoints can get persisted when canPersist flag is present
3. All breakpoint actions work (context menu, shortcuts, middle mouse click) with data breakpoints

@weinand can you please check the changes in the EH area where I introduced a new type DataBreakpoint

[isidorn]

@misolori we introduced data breakpoints. You can read more about them in this issue: basically a user sets them for a variable and the breakpoint gets hit when that variable gets modified.

Since we already have special icons for function breakpoints. We also need a new icon for data breakpoints.
Since we already use a triangle and a circle. Maybe we go with a square?
Is it possible that you design some icon for data breakpoints?

Here's a picture where data breakpoints would be seen in the breakpoints view

[isidorn]

If a debug adapter supports data breakpoints it is possible to add them via the context menu on a variable in the VARIABLES view.

I have added code that data breakpoints get cleared when the session ends.
So the only thing for this milestone which we plan to add is the data breakpoint icon with @misolori

@gregg-miskelly @pieandcakes @WardenGnaw you can try out data breakpoints in latest VS Code insiders and let us know what you think.

Currently we just decorate the CALL STACK view with the reason which can be stopped on data breakpoint.
For a clearer indication for the user we have two options for the future:

1. Render an inline decoration in the Editor (similar to the inline Exception Widget)
2. Reveal the modified varialbe in the VARIABLE view and select it (similar to how Explorer reveals file when a user executes Reval Active File in Side Bar)

The first option we could easily do and it is pretty generic, as we would just show the description of the Data Breakpoint or some other field that we agree upon.
The second option is more tricky as it would need a stricter relationship between a data breakpoint and a variable. VS Code would have to be notified of the whole parent chaing of the variable in order to be able to expand all the elements. This stricter relationship would also help us to add some Data Breakpoint actions in the EXPRESSIONS view. Downside of this is that data breakpoints would get more tied to the variables, and in practice I am not sure if that is always the case in your debug extensions.

Currently it is not possible to add conditions and hit counts to data breakpoints. We can look into adding this in the future.
It is also not possible to add explicitly the adress - we could easily add this action to the breakpoints view if we decide we need it.

Let me know what you think and thanks

[isidorn]

Closing since we have tackled this initialy in this milestone.
For additional improvments we will file new feature requests.