Add support for data breakpoints

[colin-grant-work]

What it does

Closes #16445

This PR hooks up the DAP's data breakpoint requests to Theia's debug system.

How to test

0. Using a debug adapter that supports data breakpoints...

Note

As noted in #16445, the CDT-GDB Adapter supports data breakpoints. In my testing, I used Rust with Code LLDB

1. Start a debug session and hit a breakpoint.
2. There are two ways to create a data breakpoint:
   1. On a variable:
      1. In the variables view, open a context menu on a variable.
      2. Three options should be shown, to break on Change, Read, or Access, though it may be that not all are enabled for a given variable - that depends on the adapter.
      3. Select one of those options.
      4. A breakpoint should appear in the breakpoints view indicating the value watched (exact content depends on adapter) and on what kind of access the breakpoint will be hit.
      5. The breakpoint should be hit when appropriate (subject to adapter behavior).
   2. On an address:
      1. If the session supports data breakpoints, a new toolbar item will be available on the breakpoints view, and a new command to 'Add Data Breakpoint at Address' will appear in the command palette.
      2. Trigger that command
      3. You will be asked to enter a range to watch and then select an access type.

      [!NOTE]
      If you watch a variable with the LLDB adapter, it will report the address and range. You can then use that information to construct a valid range e.g. in a subset of that variable's range.

      4. Once the details have been set, the breakpoint should appear in the breakpoint view.
      5. A context menu item should appear on such a breakpoint to edit its address, as well.

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[chroberino]

@colin-grant-work, many thanks for implementing this feature -- great to see data breakpoints coming to Theia!

I tested the PR locally by checking out the branch in my Theia repo clone and building the Theia Electron app.
I used cdt-gdb-vscode 2.4.1, which supports data breakpoints in VS Code.

In Theia, I do see the three context menu entries (Break When Value Changes / Is Read / Is Accessed) on variables (see screenshot), but they don’t seem to have any effect -- no data breakpoint appears in the Breakpoints view, and execution never stops as expected.

However, I can see this in Theia's developer tools console for every attempt to add a data breakpoint via the context menu:

command.ts:345 Uncaught (in promise) Error: The command 'break-on-read:d70b0d73-4494-49dd-ae5f-6f3d359cd4d7:result' cannot be executed. There are no active handlers available for the command.
    at CommandRegistry.executeCommand (command.ts:345:29)
    at ActionMenuNode.run (action-menu-node.ts:102:30)
    at execute (browser-menu-plugin.ts:348:47)
    at CommandRegistry.execute (index.ts:440:27)
    at DynamicMenuWidget.triggerActiveItem (menu.ts:316:21)
    at DynamicMenuWidget._evtMouseUp (menu.ts:708:10)
    at DynamicMenuWidget.handleEvent (menu.ts:492:14)
    at DynamicMenuWidget.handleEvent (browser-menu-plugin.ts:262:15)
executeCommand @ command.ts:345
run @ action-menu-node.ts:102
execute @ browser-menu-plugin.ts:348
execute @ index.ts:440
triggerActiveItem @ menu.ts:316
_evtMouseUp @ menu.ts:708
handleEvent @ menu.ts:492
handleEvent @ browser-menu-plugin.ts:262

Also, I don’t see the “Add Data Breakpoint at Address” command in the Command Palette, nor the new toolbar item in the Breakpoints view.

Let me know if there are any additional steps or configuration needed to enable these features.

[chroberino]

PS: I have added this line at the beginning of getVariableCommands() in packages\debug\src\browser\view\debug-variables-widget.ts:

console.log("~~~ currentSession?.capabilities", currentSession?.capabilities);

It gave me this console output:

root INFO ~~~ currentSession?.capabilities {
  supportsConfigurationDoneRequest: true,
  supportsEvaluateForHovers: true,
  supportsSetVariable: true,
  supportsConditionalBreakpoints: true,
  supportsHitConditionalBreakpoints: true,
  supportsLogPoints: true,
  supportsFunctionBreakpoints: true,
  supportsDisassembleRequest: true,
  supportsReadMemoryRequest: true,
  supportsWriteMemoryRequest: true,
  supportsSteppingGranularity: true,
  supportsInstructionBreakpoints: true,
  supportsTerminateRequest: true,
  supportsDataBreakpoints: true,
  breakpointModes: [
    {
      label: 'Hardware Breakpoint',
      mode: 'hardware',
      appliesTo: [Array]
    },
    {
      label: 'Software Breakpoint',
      mode: 'software',
      appliesTo: [Array]
    }
  ]
}

This seems to confirm that data breakpoints are definitely supported by cdt-gdb-adapter.

[chroberino]

Shouldn't this check for this.capabilities.supportsDataBreakpoints?

[colin-grant-work]

It should indeed - bad copy paste.

[colin-grant-work]

This likely explains why data breakpoints weren't being rendered for you: looks like I was testing in a case where both instruction breakpoints and data breakpoints were supported, so this mismatch didn't affect the rendering in my case, but in yours, instruction breakpoints weren't supported, so this method was behaving incorrectly.

[colin-grant-work]

Also, I don’t see the “Add Data Breakpoint at Address” command in the Command Palette, nor the new toolbar item in the Breakpoints view.

PS: I have added this line at the beginning of getVariableCommands() in packages\debug\src\browser\view\debug-variables-widget.ts:

@chroberino, with this set of capabilities, you should not see that command. It depends on the supportsDataBreakpointBytes capability, rather than the supportsDataBreakpoints capability.

  /**
   * The debug adapter supports the `asAddress` and `bytes` fields in the
   * `dataBreakpointInfo` request.
   */
  supportsDataBreakpointBytes?: boolean;

On the other hand, it looks like that's supposed to be treated as defaulting to true, so I'll switch that logic around.

[chroberino]

@colin-grant-work, I have just tested with your latest changes. I can set data breakpoints, now!
However, breakpoint hitting behaviour is not as expected. Not sure what's the issue, I will need investigate the behaviour in more detail.

What I also noticed: I guess it is not intended to allow users adding data breakpoints also via the "Debug Console" window?

[colin-grant-work]

What I also noticed: I guess it is not intended to allow users adding data breakpoints also via the "Debug Console" window?

No, I haven't added the command to that location. I don't see that mechanism in VSCode, so it wasn't something I was aiming ot implement. It would be possible, but it seems more consistent with the mechanisms for adding other breakpoints to have the icon in the breakpoints view, as is done in VSCode, and similar to the 'Add Function Breakpoint' icon in Theia. You should see it there:

[chroberino]

No, I haven't added the command to that location. I don't see that mechanism in VSCode, so it wasn't something I was aiming ot implement.

I have this icon it in both places:

[chroberino]

Thanks again, @colin-grant-work, I’ve tested with your latest change, and the misplaced data breakpoint icon in the "Debug Console" window is gone now.

However, breakpoint hitting behaviour is not as expected. Not sure what's the issue, I will need investigate the behaviour in more detail.

After some investigation, I found this breakpoint hitting issue isn’t specific to Theia, it behaves the same in VS Code as well (=> eclipse-cdt-cloud/cdt-gdb-adapter#458 (comment))

I’ve noticed one remaining point:
Unlike in VS Code, data breakpoints are removed when the debug session ends.
While memory addresses can change between target reboots, there are valid scenarios where no reboot occurs, and the same addresses remain valid across sessions -- so persisting data breakpoints would be useful in such cases.

[colin-grant-work]

Unlike in VS Code, data breakpoints are removed when the debug session ends.
While memory addresses can change between target reboots, there are valid scenarios where no reboot occurs, and the same addresses remain valid across sessions -- so persisting data breakpoints would be useful in such cases.

Hm... I suspect that this is another case where I'm supposed to treat something undefined as true. In VSCode, all address breakpoints are treated as though the debug adapter had responded with canPersist true, but to me, the debug adapter really should say whether it thinks it's safe to persist an address-based BP. But it's an easy change.

[chroberino]

@colin-grant-work, I have just noticed that you have already worked on persisting data breakpoints. 🙏

I did notice the following issue with that:
When ending a debug session, data breakpoints remain visible (but greyed out) in the Breakpoints view (which is fine). However, when starting a new debug session, those breakpoints disappear from the list entirely.
Interestingly, as soon as I add another data breakpoint, all previously defined ones reappear (along with the new one).

I’ve recorded a screen capture demonstrating the behavior:
https://github.com/user-attachments/assets/d788f06d-cde6-4394-b990-80730799aa70

[chroberino]

@colin-grant-work, great news! I finally got everything working!
Huge thanks for all the effort that went into making data breakpoints work smoothly in Theia!