Difference between revisions of "CDT/Archive/Debug/Catchpoints support"

Revision as of 17:03, 18 April 2008

Overview

This document describe design ideas of adding catchpoints support to CDT. Catchpoints is special breakpoints which is similar to event handlers in eclipse, they don't attach to resource like regular breakpoints; but instead they attach to debugger events. Event can be for example "catch exception" or something like "load library event".

Please leave your comments here: Talk:CDT:_Debug:_Catchpoints_support

Workflow & UI

• Adding catchpoint
  • From breakpoints view, invoke action Add Event Breakpoint...

Dialog opens. Dialog contains type of event to catch and maybe additional argument field. User edit it press Ok.

Creating extensible Add Breakpoint contributions is covered by bug 227394. It most likely not going to make Ganymede so for now I can just add it context menu or in view menu.

If no contributions to catchpoint types been made, action should be disabled or give appropriate error when attempt to run

• • From console, triggers adding breakpoints by backend - Breakpoint appears in the list
• Removing catchpoint
  • Removing catchpoint from breakpoints view, select breakpoint, right click -> Delete
  • From console, triggers deleting breakpoint by backend
• Viewing/Editing
  • Catchpoint is visible as Element in Breakpoints view. Label contains event type label and argument, followed by default cbreakpoint attributes
  • Select catchpoint in breakpoints view, right click -> Show breakpoint properties
  • Catchpoint properties contain common page, conditions and triggered actions.
  • Common tab is similar to regular breakpoint except file/line stuff, and in addition it has event type and extra control for event argument (viewing or editing).

Catchpoint contributions

• Main Catchpoints attributes would consist of Catchpoint type (event type - String) and Extra argument (Object)
• We need the following contributions one way or another:
• 1) Label for event type. This will be visible in Breakpoints view as a part of element Label, in Add Breakpoint wizard/dialog, in Breakpoint Properties
• 2) Part of label for event argument, to be visible in Breakpoint view
• 3) Custom control for creating event argument, in Add Breakpoint wizard/dialog
• 4) Custom control for viewing/modifying event argument, for Common properties page

To implement 1 we need some sort of catchpoint type registry.

To implement 2:

• 2a Use toString method of Argument type in catchpoint label provider
• 2b Implement adapters mechanism for ILabelProvider (Breakpoints view does not support IElementLabelProvider yet)

To implement 3 and 4 we can use same control, which can contributed using extensions points

Now if we generalize it we can have:

• Mechanism to register a static label (text) for a new breakpoint attribute value

this allows to handle event type Label and Label for other breakpoint attributes such as hardware/software type

example: text for "gdb.catch" event type (value of org.eclipse.cdt.debug.breakpoint.type attribute) is "Exception Caught"

• Mechanism to register Label provider for a new breakpoint type element

this allows to show label for non-standard breakpoint type, like Catchpoint itself at the moment

example: register adapter for ILabelProvider on ICCatchpoint. getText() returns concatenation of event type label, extra argument, condition and count.

• Mechanism to register a list of supported values of a new breakpoint attribute

this would allow to register possible catchpoint events.

example: extension that list contributes event types from gdb backend

• Mechanism to register extension Control for Common property page to show a new breakpoint attribute

this allows to actually view custom breakpoint attributes in Common page. If it is just one attribute added such as breakpoint type: hardware/software viewing them in separate property page is overkill

example: extension that contribute property page to create extra argument (C/C++ type) for exception catchpoint.

Implementation

• CBreakpoint already provides extensibility mechanism that can be used for catchpoint contributions (BreakpointExtention)?
• To represent event type there is two options: use marker type or use marker attribute. I will go with attribute for now.

Public API

• Add interface org.eclipse.cdt.debug.core.model.ICCatchpoint extends ICBreakpoint
  • In there define strings for 2 addition marker attributes: event type id and event argument
  • Define 2 getter methods for these attribute
• Add interface org.eclipse.cdt.debug.core.cdi.model.ICDICatchpoint extends ICDIBreakpoint

Other changes

• Add class org.eclipse.cdt.debug.internal.core.breakpoints.CCatchpoint extends CBreakpoint implements ICCatchpoint
• Add org.eclipse.debug.core.breakpoints extension for breakpoint markers
• Add createCatchpoint method in CDTDebugModel
• Support in CBreakpointManager handleBreakpontCreatedEvent

...

Platform UI (or CDT) extension for marker attribute externalizable values

<extension id="com.xyz.coolMarkerLabels" point="org.eclipse.cdt.debug.ui.breakpointContribution">
    <breakpointLabels markerId="com.xyz.coolMarker"> 
    <attribute name="owner" label="Resource Owner">
       <value value="harris.bob" label="Bob Harris"/>
       <value value="harris.mary" label="Mary Harris"/>
    </attribute> 
    </breakpointLabels>
</extension>

<extension point="org.eclipse.cdt.debug.ui.breakpointContribution">
    <breakpointLabels markerId="org.eclipse.cdt.debug.core.catchpoint"> 
    <attribute name="org.eclipse.cdt.debug.core.catchpoint.type" label="Catchpoint Type" type="enum">
       <value value="gdb.catch" label="Exception Caught">
           <attribute name="org.eclipse.cdt.debug.core.catchpoint.argument" label="C/C++ Type" 
                type="string" fieldEditor="org.eclipse.cdt.debug.ui.breakpoints.CTypeSelectorEditor">
           </attribute>
       </value>
       <value value="gdb.throw" label="Exception Thrown"/>
       <value value="gdb.signal" label="Signal Caught">
           <attribute name="org.eclipse.cdt.debug.core.catchpoint.argument" label="Signal Number" 
                type="integer" fieldEditor="IntegerFieldEditor">
           </attribute>
       </value>
    </attribute> 
    </breakpointLabels>
</extension>