Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDT/Archive/designs/Tracepoints"

< CDT‎ | Archive‎ | designs
Line 64: Line 64:
  
 
[[Image:BreakpointType.png]]
 
[[Image:BreakpointType.png]]
 +
 +
Note that Tracepoints will not be activated when the feature is not supported.  Therefore, for CDI-GDB, this breakpoint-type selection will not be visible.  It will also not be shown for DSF-GDB when running with a version of GDB that does not support the proper tracepoint functionality.  We also propose to add this breakpoint type menu to the editor margin.  This is also provided by the platform, but not visible by default.  We will make it visible in the CEditor:
 +
 +
[[Image:BreakpointTypeInEditor.png]]

Revision as of 16:18, 4 January 2010

Introduction

This page describes the proposed design for support of Tracepoints in the CDT. The design is divided into multiple phases. The first phase is restricted to the control of tracepoints, which includes creation, deletion and configuration. Further phases will address the actual collection and visualization of tracing data. This multi-phase approach aims as making the review process easier.

The proposed solution attempts to make tracepoint-support generic to allow for the easy integrations of different backends. However, an actual implementation using GDB Tracepoints will also be contributed but only for the existing DSF-GDB integration.

Definitions

This page is based on the below characteristics of tracepoints. The tracepoint concept is extremely similar to the breakpoint concept. Like breakpoints, tracepoints have the following characteristics:

  • can be created and deleted based on a line of code or address or function
  • can be enabled or disabled
  • can have an associated condition
  • can have an associated ignore-count (not supported by GDB)
  • can be associated to a specific set of threads (not supported by GDB)
  • can have an associated list of commands (in GDB those commands are limited to 'eval', 'while-stepping' and 'collect')
  • can be imported/exported from/to a file

Some of the characteristics specific to tracepoints are:

  • can have an associated passcount which, when reached, will turn off the data collection
  • can use trace-state variables (see Trace-state Variables section) (could be considered GDB-specific)
  • can have a set of global commands which are attached to all tracepoints (could be considered GDB-specific)
  • can remain defined on a target even if the backend is no longer connected to the target. This implies then when connecting to a target, tracepoints may already exist on that target.
  • has an extra state, 'active', which indicates that the tracepoint is part of on-going tracing.

Trace-state Variables

Trace-state variables are variables defined in the backend that are dedicated to tracing. These variables can be examined and modified within tracepoint conditions and tracepoint commands.

First Phase

The first phase of the design deal with how we propose to:

  • create/delete tracepoints
  • enable/disable tracepoints
  • add conditions to tracepoints
  • add an ignore-count to a tracepoint
  • add a passcount to a tracepoint

Second Phase

The second phase of development will focus on the following items:

  • tracepoint actions
  • global tracepoint actions
  • performing tracing (start, stop, status, etc)
  • use of trace-state variables
  • active tracepoints
  • visualizing trace data

Third Phase

The last phase of development will deal with more advanced concepts such as:

  • Disconnected tracing
  • import/export tracepoints from file
  • fast versus slow tracepoints
  • observer mode

First Phase Details

Tracing Action Set

First, a new Action Set will be created to include all tracepoint-related actions and allow a user to hide them. By default this Action Set will not be visible. ActionSet.png

Tracepoint as a type of breakpoint

Since tracepoints are so similar to breakpoints, we propose to treat Tracepoints as a new type of breakpoint, as supported by the IToggleBreakpointsTarget interface. This approach will allow to re-use the existing breakpoint UI to handle Tracepoints. This means that breakpoint menus will be used by tracepoints, and that tracepoints will be included in the Breakpoints View. The user will simply need to select which type of 'breakpoint' is currently to be used. The UI for this selection is already part of the platform:

BreakpointType.png

Note that Tracepoints will not be activated when the feature is not supported. Therefore, for CDI-GDB, this breakpoint-type selection will not be visible. It will also not be shown for DSF-GDB when running with a version of GDB that does not support the proper tracepoint functionality. We also propose to add this breakpoint type menu to the editor margin. This is also provided by the platform, but not visible by default. We will make it visible in the CEditor:

BreakpointTypeInEditor.png

Back to the top