[all-commits] [llvm/llvm-project] 2aa1dd: [trace] Add a TraceCursor class

[walter erquinigo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2aa1dd1c66dc3b1f6253eec9fc68c081a945b74d
      https://github.com/llvm/llvm-project/commit/2aa1dd1c66dc3b1f6253eec9fc68c081a945b74d
  Author: Walter Erquinigo <wallace at fb.com>
  Date:   2021-06-23 (Wed, 23 Jun 2021)

  Changed paths:
    M lldb/include/lldb/Target/Trace.h
    A lldb/include/lldb/Target/TraceCursor.h
    M lldb/include/lldb/lldb-defines.h
    M lldb/include/lldb/lldb-enumerations.h
    M lldb/include/lldb/lldb-forward.h
    M lldb/source/Plugins/Trace/intel-pt/CommandObjectTraceStartIntelPT.cpp
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
    M lldb/source/Target/CMakeLists.txt
    M lldb/source/Target/Trace.cpp
    A lldb/source/Target/TraceCursor.cpp

  Log Message:
  -----------
  [trace] Add a TraceCursor class

As a follow up of D103588, I'm reinitiating the discussion with a new proposal for traversing instructions in a trace which uses the feedback gotten in that diff.

See the embedded documentation in TraceCursor for more information. The idea is to offer an OOP way to traverse instructions exposing a minimal interface that makes no assumptions on:

- the number of instructions in the trace (i.e. having indices for instructions might be impractical for gigantic intel-pt traces, as it would require to decode the entire trace). This renders the use of indices to point to instructions impractical. Traces are big and expensive, and the consumer should try to do look linear lookups (forwards and/or backwards) and avoid random accesses (the API could be extended though, but for now I want to dicard that funcionality and leave the API extensible if needed).
- the way the instructions are represented internally by each Trace plug-in. They could be mmap'ed from a file, exist in plain vector or generated on the fly as the user requests the data.
- the actual data structure used internally for each plug-in. Ideas like having a struct TraceInstruction have been discarded because that would make the plug-in follow a certain data type, which might be costly. Instead, the user can ask the cursor for each independent property of the instruction it's pointing at.

The way to get a cursor is to ask Trace.h for the end or being cursor or a thread's trace.

There are some benefits of this approach:
- there's little cost to create a cursor, and this allows for lazily decoding a trace as the user requests data.
- each trace plug-in could decide how to cache the instructions it generates. For example, if a trace is small, it might decide to keep everything in memory, or if the trace is massive, it might decide to keep around the last thousands of instructions to speed up local searches.
- a cursor can outlive a stop point, which makes trace comparison for live processes feasible. An application of this is to compare profiling data of two runs of the same function, which should be doable with intel pt.

Differential Revision: https://reviews.llvm.org/D104422