[all-commits] [llvm/llvm-project] ea1f49: [intel pt] Refactor parsing

[walter erquinigo via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: ea1f49741ec4c0a37796b88f6bb8d09d7ab1e8c3
      https://github.com/llvm/llvm-project/commit/ea1f49741ec4c0a37796b88f6bb8d09d7ab1e8c3
  Author: Walter Erquinigo <wallace at fb.com>
  Date:   2020-10-09 (Fri, 09 Oct 2020)

  Changed paths:
    M lldb/include/lldb/Core/PluginManager.h
    M lldb/include/lldb/Target/Trace.h
    A lldb/include/lldb/Target/TraceSessionFileParser.h
    R lldb/include/lldb/Target/TraceSettingsParser.h
    M lldb/include/lldb/lldb-forward.h
    M lldb/include/lldb/lldb-private-interfaces.h
    M lldb/source/Commands/CommandObjectTrace.cpp
    M lldb/source/Core/PluginManager.cpp
    M lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
    A lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.cpp
    A lldb/source/Plugins/Trace/intel-pt/ThreadIntelPT.h
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
    A lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.cpp
    A lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSessionFileParser.h
    R lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSettingsParser.cpp
    R lldb/source/Plugins/Trace/intel-pt/TraceIntelPTSettingsParser.h
    M lldb/source/Target/CMakeLists.txt
    M lldb/source/Target/Trace.cpp
    A lldb/source/Target/TraceSessionFileParser.cpp
    R lldb/source/Target/TraceSettingsParser.cpp
    M lldb/test/API/commands/trace/TestTraceLoad.py
    M lldb/test/API/commands/trace/TestTraceSchema.py

  Log Message:
  -----------
  [intel pt] Refactor parsing

With the feedback I was getting in different diffs, I realized that splitting the parsing logic into two classes was not easy to deal with. I do see value in doing that, but I'd rather leave that as a refactor after most of the intel-pt logic is in place. Thus, I'm merging the common parser into the intel pt one, having thus only one that is fully aware of Intel PT during parsing and object creation.

Besides, based on the feedback in https://reviews.llvm.org/D88769, I'm creating a ThreadIntelPT class that will be able to orchestrate decoding of its own trace and can handle the stop events correctly.

This leaves the TraceIntelPT class as an initialization class that glues together different components. Right now it can initialize a trace session from a json file, and in the future will be able to initialize a trace session from a live process.

Besides, I'm renaming SettingsParser to SessionParser, which I think is a better name, as the json object represents a trace session of possibly many processes.

With the current set of targets, we have the following

- Trace: main interface for dealing with trace sessions
- TraceIntelPT: plugin Trace for dealing with intel pt sessions
- TraceIntelPTSessionParser: a parser of a json trace session file that can create a corresponding TraceIntelPT instance along with Targets, ProcessTraces (to be created in https://reviews.llvm.org/D88769), and ThreadIntelPT threads.
- ProcessTrace: (to be created in https://reviews.llvm.org/D88769) can handle the correct state of the traces as the user traverses the trace. I don't think there'll be a need an intel-pt specific implementation of this class.
- ThreadIntelPT: a thread implementation that can handle the decoding of its own trace file, along with keeping track of the current position the user is looking at when doing reverse debugging.

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