Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDT/Archive/designs/Tracepoints

< CDT‎ | Archive‎ | designs
Revision as of 15:52, 4 January 2010 by Unnamed Poltroon (Talk) (New page: == 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 contro...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

Back to the top