microsoft
Extend support for data breakpoints in VS Code API
What it does
The breakpoint API in VS Code supports to add
- Allow the user to manage data breakpoints through vscode.debug API
- Add methods to gain information about a potential data breakpoint
- Allow data breakpoints to have different sources
- Keep use case where data id is already known (current)
- Add infrastructure for already existing address resolution
- Extend for dynamic variables resolved for a session
- Ensure dynamic variables are resolved in the debug model
Communication:
- Adapt DataBreakpoint with source between extension host and main
- Expose DataBreakpoint in VS Code API, previously not exposed (should not cause any backwards compatibility issues)
Minor:
- Make bytes optional in data bytes info, as it is the same in the DAP
Fixes https://github.com/microsoft/vscode/issues/195151
How to test
To test this change, you need to make sure you have a C++ file that you can debug as the Typescript debugger does not support data breakpoints as far as I can see.
- Install VS Code C++ Tools
- Create a C++ file, e.g.,
#include <iostream>
int main() {
int counter = 0;
for (int i = 0; i < 10; i++) {
counter++;
std::cout << "Counter: " << counter << std::endl;
}
return 0;
}
- Create and start an extension (or modify an existing one that is already started with VS Code) with the code similar to this one:
vscode.debug.onDidChangeBreakpoints(evt => {
vscode.window.showInformationMessage(JSON.stringify(evt, undefined, 2));
});
vscode.debug.onDidChangeActiveDebugSession(session => {
setTimeout(async () => {
try {
const info = await session?.getDataBreakpointInfo('i', 1000);
vscode.window.showInformationMessage(JSON.stringify(info, undefined, 2));
} catch (error) {
vscode.window.showErrorMessage(error.message);
}
try {
const info = await session?.getDataBytesBreakpointInfo('0x7fffffffd7e8', 4);
vscode.window.showInformationMessage(JSON.stringify(info, undefined, 2));
} catch (error) {
vscode.window.showErrorMessage(error.message);
}
}, 2000);
});
vscode.debug.addBreakpoints([
new vscode.DataBreakpoint({ type: 'variable', dataId: '0x7fffffffd7e8,counter,4' }, 'readWrite', false, '', false, 'condition', 'hitCondition', 'logMessage'),
new vscode.DataBreakpoint({ type: 'address', address: '0x7fffffffd7e8', bytes: 4 }, 'readWrite', false, '', false, 'condition', 'hitCondition', 'logMessage'),
new vscode.DataBreakpoint({ type: 'dynamicVariable', name: 'i', variablesReference: 1000 }, 'readWrite', false, '', false, 'condition', 'hitCondition', 'logMessage')
]);
When starting the extension you should already see the three data breakpoints that you added:
- Enable the data breakpoints (or already produce them enabled in your extension code).
- Debug the program with the
Debug C/C++ Filecommand. - Depending on your other setup not all breakpoints may resolve correctly but you can see that they are properly evaluated.
@thegecko FYI, I believe you have also shown interest in this issue at some point.
@roblourens Thank you very much for your quick feedback, I really appreciate it!
Regarding the retrieval of the variable information, please see my inline comment.
As for the use cases: The original ticket describes a scenario where a data breakpoint feature is needed for a remote debugger. However, I do not have any details on that. The particular use case we are working on has to do with a dedicated memory view where we wanted to support setting data breakpoints through a context menu in our custom UI. The VS Code Debug UIs already have all the necessary access and many bits and pieces were already in place for most of the other breakpoint types. However, we hit a wall particularly with data breakpoints as they are not exposed in the extension API even though most of the functionality was already in place on the "main" side and only a few if-branches were missing on the extension host side. So the core of this change is really rather small and trying to align the support of data breakpoints with the support of other breakpoints. If you have any further questions, please let me know.
I just wanted to check in and see if there's been any progress on reviewing the PR. Let me know if there's anything I can do to help move it forward. Thank you!
@connor4312 Thank you very much for your feedback, I'll have a more detailed look this week!
@connor4312 Thank you very much for your very valuable feedback! I pushed another commit to move the data breakpoint resolution to an earlier point in time and properly propagate the resolution result throughout VS Code. I'm sure there are still areas to improve and I'd be happy to get more feedback but I want to make sure I'm on the right track here.
@connor4312 @roblourens Could we have an update on this PR, please?
Is there any more which needs changing?
@connor4312 Hi there! I'd like to ask if there's a chance of getting this PR merged. We're happy to rebase and resolve conflicts if you think it's worth moving forward. Thank you!
@connor4312 Thank you very much for getting back to this! It took me some time to pick that up again and update it to the latest main but I believe now the API is much cleaner! We now have a much cleaner workflow from "origin" (previously "source") to "info" (previously "resolution") to the actual data breakpoint. We also handle the global nature of the data breakpoint more elegantly by storing the info per session. I think we have a very nice API now but please let me know if you like something changed.
@connor4312 I see that the 'Code OSS' check seems to fail but I do not have the credentials to look at the actual log. If it is something I need to fix, could you please show me the output somehow.
That should be open to the public, you can't see https://dev.azure.com/vscode/VSCode/_build/results?buildId=149534&view=results? I can load it in a window where I'm not logged in.
The failure is
1) Debug - Breakpoints
data breakpoints:
AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
0 !== 'variable'
at Context.<anonymous> (file:///mnt/vss/_work/1/s/out/vs/workbench/contrib/debug/test/browser/breakpoints.test.js:264:12)
@roblourens Thank you for your quick response! I fixed the test case now.
When I clicked on the Code OSS link of the failed job in this PR, I was asked to sign in and then got an error but I just tried it on my phone and there it works so it actually is something I need to figure out on my side. Sorry for that!
@connor4312 @roblourens could you give us an update on this PR? Is there something missing that needs to be addressed?
Could someone knowledgeable please have a look at this PR again (e.g. resolve conflicts) to move it forward? Thanks a lot!
I'm happy to resolve the conflicts after getting some "official" feedback as otherwise this PR will only become stale again.