Skip to content

Commit d52ba48

Browse files
author
Walter Erquinigo
committed
[trace] Introduce Hierarchical Trace Representation (HTR) and add command for Intel PT trace visualization
This diff introduces Hierarchical Trace Representation (HTR) and creates the `thread trace export ctf -f <filename> -t <thread_id>` command to export an Intel PT trace's HTR to Chrome Trace Format (CTF) for visualization. See `lldb/docs/htr.rst` for context/documentation on HTR. **Overview of Changes** - Add HTR documentation (see `lldb/docs/htr.rst`) - Add HTR structures (layer, block, block metadata) - Implement "Basic Super Block" HTR pass - Add 'thread trace export ctf' command to export the HTR of an Intel PT trace to Chrome Trace Format (CTF) As this diff is the first iteration of HTR and trace visualization, future diffs will build on this work by generalizing the internal design of HTR and implementing new HTR passes that provide better trace summarization/visualization. See attached video for an example of Intel PT trace visualization: {F17851042} Original Author: jj10306 Submitted by: wallace Reviewed By: wallace, clayborg Differential Revision: https://reviews.llvm.org/D105741
1 parent e12e02d commit d52ba48

File tree

12 files changed

+1119
-8
lines changed

12 files changed

+1119
-8
lines changed

lldb/docs/htr.rst

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
Hierarchical Trace Representation (HTR)
2+
======================================
3+
The humongous amount of data processor traces like the ones obtained with Intel PT contain is not digestible to humans in its raw form. Given this, it is useful to summarize these massive traces by extracting useful information. Hierarchical Trace Representation (HTR) is the way lldb represents a summarized trace internally. HTR efficiently stores trace data and allows the trace data to be transformed in a way akin to compiler passes.
4+
5+
Concepts
6+
--------
7+
**Block:** One or more contiguous units of the trace. At minimum, the unit of a trace is the load address of an instruction.
8+
9+
**Block Metadata:** Metadata associated with each *block*. For processor traces, some metadata examples are the number of instructions in the block or information on what functions are called in the block.
10+
11+
**Layer:** The representation of trace data between passes. For Intel PT there are two types of layers:
12+
13+
**Instruction Layer:** Composed of the oad addresses of the instructions in the trace. In an effort to save space,
14+
metadata is only stored for instructions that are of interest, not every instruction in the trace. HTR contains a
15+
single instruction layer.
16+
17+
**Block Layer:** Composed of blocks - a block in *layer n* refers to a sequence of blocks in *layer n - 1*. A block in
18+
*layer 1* refers to a sequence of instructions in *layer 0* (the instruction layer). Metadata is stored for each block in
19+
a block layer. HTR contains one or more block layers.
20+
21+
**Pass:** A transformation applied to a *layer* that generates a new *layer* that is a more summarized, consolidated representation of the trace data.
22+
A pass merges instructions/blocks based on its specific purpose - for example, a pass designed to summarize a processor trace by function calls would merge all the blocks of a function into a single block representing the entire function.l
23+
24+
The image below illusrates the transformation of a trace's representation (HTR)
25+
26+
.. image:: media/htr-example.png
27+
28+
Passes
29+
------
30+
A *pass* is applied to a *layer* to extract useful information (summarization) and compress the trace representation into a new *layer*. The idea is to have a series of passes where each pass specializes in extracting certain information about the trace. Some examples of potential passes include: identifying functions, identifying loops, or a more general purpose such as identifying long sequences of instructions that are repeated (i.e. Basic Super Block). Below you will find a description of each pass currently implemented in lldb.
31+
32+
**Basic Super Block Reduction**
33+
34+
A “basic super block” is the longest sequence of blocks that always occur in the same order. (The concept is akin to “Basic Block'' in compiler theory, but refers to dynamic occurrences rather than CFG nodes).
35+
36+
The image below shows the "basic super blocks" of the sequence. Each unique "basic super block" is marked with a different color
37+
38+
.. image:: media/basic_super_block_pass.png
39+
40+
*Procedure to find all super blocks:*
41+
42+
- For each block, compute the number of distinct predecessor and successor blocks.
43+
44+
- **Predecessor** - the block that occurs directly before (to the left of) the current block
45+
- **Successor** - the block that occurs directly after (to the right of) the current block
46+
47+
- A block with more than one distinct successor is always the start of a super block, the super block will continue until the next block with more than one distinct predecessor or successor.
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1 +1,2 @@
1+
add_subdirectory(common)
12
add_subdirectory(ctf)
Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
add_lldb_library(lldbPluginTraceExporterCommon
2+
TraceHTR.cpp
3+
4+
LINK_LIBS
5+
lldbCore
6+
lldbTarget
7+
)

0 commit comments

Comments
 (0)