Community
Participate
Working Groups
For any debug context a breakpoint's state on the corresponding target can be one of the following: 1. not installed 2. installed 3. pending. Currently the breakpoint's image indicates that it is either installed on a target or not installed on all targets. It would be good if the image could change according to the breakpoint's state for the current debug context.
Pushed a patch to Gerrit: https://git.eclipse.org/r/#/c/25848/. Marc, can you please take a look?
Here is some explanations on the decisions made when implementing this feature: 1. All debug models (DSF, CDI, etc.) use the same org.eclipse.cdt.debug.ui.CDebugModelPresentation class to render breakpoints. That's the reason why I had to add the new images to the same plugin even though they are currently used by DSF/GDB only. 2. Besides 1, the entire feature could have be implemented in org.eclipse.cdt.dsf.gdb.ui if there was a better way to activate the class that listens to DSF sessions before ANY session is started. To make it work I had to define a new interface (IBreakpointUpdater) and an extension point (org.eclipse.cdt.dsf.gdb.breakpointUpdater). This seems too complicated but I haven't been able to find a better solution. 3. If a breakpoint is installed in at least one of the currently active sessions it has a check mark in its image. It's a bit of a redundancy but using only colors to differentiate between installed and not installed breakpoints may raise accessibility issues so I decided to leave the check mark. 4. When a debug context is not an IBreakpointsTargetDMContext the breakpoints are not rendered as installed or pending even though the context element is part of the session. This applies to ILaunch and IProcess elements. It seems a bit odd, especially when using the GDB console, but there is no easy fix for it.
(In reply to Mikhail Khodjaiants from comment #1) > Pushed a patch to Gerrit: https://git.eclipse.org/r/#/c/25848/. I wanted to give this feature a spin but I'm hitting some assertions about not running in the DSF Executor thread. Can you try to run with -ea and see if you get them too? java.lang.AssertionError at org.eclipse.cdt.dsf.service.DsfServicesTracker.getServiceReference(DsfServicesTracker.java:179) at org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker.java:224) at org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker.java:209) at org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.GdbBreakpointUpdater.doUpdateBreakpoints(GdbBreakpointUpdater.java:123) at org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.GdbBreakpointUpdater.debugContextChanged(GdbBreakpointUpdater.java:113) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService$1.run(DebugWindowContextService.java:223)
(In reply to Marc Khouzam from comment #3) > (In reply to Mikhail Khodjaiants from comment #1) > > Pushed a patch to Gerrit: https://git.eclipse.org/r/#/c/25848/. > > I wanted to give this feature a spin but I'm hitting some assertions about > not running in the DSF Executor thread. Can you try to run with -ea and see > if you get them too? > > java.lang.AssertionError > at > org.eclipse.cdt.dsf.service.DsfServicesTracker. > getServiceReference(DsfServicesTracker.java:179) > at > org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker. > java:224) > at > org.eclipse.cdt.dsf.service.DsfServicesTracker.getService(DsfServicesTracker. > java:209) > at > org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.GdbBreakpointUpdater. > doUpdateBreakpoints(GdbBreakpointUpdater.java:123) > at > org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.GdbBreakpointUpdater. > debugContextChanged(GdbBreakpointUpdater.java:113) > at > org.eclipse.debug.internal.ui.contexts.DebugWindowContextService$1. > run(DebugWindowContextService.java:223) Thanks Marc. I pushed a new version to Gerrit.
I finally tried this patch. I just started playing with it and I'm wondering about the colours. From what I can see: blue -> uninstalled red (+ checkmark) -> installed yellow -> pending To me, red means "bad", so this scheme was confusing. What do you think of: red -> uninstalled blue (+checkmark) -> installed yellow -> pending or, if you want to keep blue for uninstalled to have everything blue when there is not debug session how about: blue -> uninstalled green (+ checkmark) -> installed yellow -> pending
In practice, with our DSF-GDB implementation starting with GDB 6.8 and up, we actually only see installed and pending breakpoints. What is the main use-case for this feature?
(In reply to Marc Khouzam from comment #5) > I finally tried this patch. I just started playing with it and I'm > wondering about the colours. From what I can see: > > blue -> uninstalled > red (+ checkmark) -> installed > yellow -> pending > > To me, red means "bad", so this scheme was confusing. > > What do you think of: > > red -> uninstalled > blue (+checkmark) -> installed > yellow -> pending > > or, if you want to keep blue for uninstalled to have everything blue when > there is not debug session how about: > > blue -> uninstalled > green (+ checkmark) -> installed > yellow -> pending I was following the "traditional" color scheme in which "red" means "stop" and "yellow" - prepare to stop. All IDEs I have seen have "red" as the color of breakpoints. If we decide to go with this patch we can post all these options to cdt-dev and see want others think. BTW, I took the breakpoint images from the "Working Set" icon. I don't have good tools to change the colors of the images, for some reason it doesn't work well, so I had to stick with the existing colors.
(In reply to Marc Khouzam from comment #6) > In practice, with our DSF-GDB implementation starting with GDB 6.8 and up, > we actually only see installed and pending breakpoints. > > What is the main use-case for this feature? Currently there is only one use case: you can delete a breakpoint from the console and will not be installed anymore. A while ago I submitted a patch that associates any address breakpoint set in the session with the binary being debugged. That patch needs to be reworked but it's an important issue when multiple debug sessions are running simultaneously: an address breakpoint set at invalid address may cause serious problems.
I have updated the patch (https://git.eclipse.org/r/#/c/25848/) to current master, with no other changes. To continue the conversation started in Comment #5. In addition to the colour options listed, the most confusing one is "blue + checkmark" which means not installed on current target. It may just be confusing because that has always been the scheme meaning installed. There are two ways of getting the "blue + checkmark" with a valid DSF target selected. Have the breakpoint installed on another target and either: a) delete the breakpoint from the current target (e.g. "del 2") b) change the breakpoint in the breakpoint filtering to be not installed Additionally, having no valid target selected (e.g. have the Launch node be the active selection) also causes the blue + checkmark. I think we should leave blue+checkmark to mean installed as the user expects. Then we are left to deal with what the user expects.
