This is an archive of the discontinued LLVM Phabricator instance.

[trace] rename ThreadIntelPT to ThreadTrace
ClosedPublic

Authored by wallace on Oct 14 2020, 10:38 AM.

Details

Summary

Renamed ThreadIntelPT to ThreadTrace, making it a top-level class. I noticed that this class can and should work with any trace plugin and there's nothing intel-pt specific in it.
With that TraceThread change, I was able to move most of the json file parsing logic to the base class TraceSessionFileParser, which makes adding new plug-ins easier.

This originally was part of https://reviews.llvm.org/D89283

Diff Detail

Event Timeline

wallace created this revision.Oct 14 2020, 10:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 14 2020, 10:38 AM
wallace requested review of this revision.Oct 14 2020, 10:38 AM
wallace retitled this revision from [trace] rename ThreadIntelPT into TraceTrace to [trace] rename ThreadIntelPT to TraceTrace.Oct 14 2020, 10:41 AM
wallace updated this revision to Diff 298208.Oct 14 2020, 12:05 PM

some cleanup

wallace retitled this revision from [trace] rename ThreadIntelPT to TraceTrace to [trace] rename ThreadIntelPT to TraceThread.Oct 14 2020, 12:07 PM
wallace edited the summary of this revision. (Show Details)

Making this a separate patch is a good idea, but it does not materially address my objections to having ProcessTrace and ThreadTrace live in two different places. :(

wallace updated this revision to Diff 298493.EditedOct 15 2020, 3:43 PM

Addressed the issues that @labath pointed out regarding the TraceProcess and TraceThread:

  • These classes were not together
  • TraceProcess was an optional plug-in, which would break the Trace parsing logic if plugged-out

So I ended up moving TraceProcess and TraceThread next to Trace in LLDB core, guaranteeing that the "trace" process plug-in will always exist and now the source file structure looks better.

Btw, it doesn't seem to me a good idea to not have TraceProcess as a plug-in even inside LLDB core, as the main API for constructing processes in Target assumes that all processes are plug-ins. I'd rather keep one single simple API instead of having two or more.

Addressed the issues that @labath pointed out regarding the TraceProcess and TraceThread:

  • These classes were not together
  • TraceProcess was an optional plug-in, which would break the Trace parsing logic if plugged-out

So I ended up moving TraceProcess and TraceThread next to Trace in LLDB core, guaranteeing that the "trace" process plug-in will always exist and now the source file structure looks better.

Yes, that looks better. My only quibble is about the naming. The prevailing lldb convention is to add a suffix to the subclass name, not prefix. So I think we should standardize on ProcessTrace & ThreadTrace and not the other way around.

Btw, it doesn't seem to me a good idea to not have TraceProcess as a plug-in even inside LLDB core, as the main API for constructing processes in Target assumes that all processes are plug-ins. I'd rather keep one single simple API instead of having two or more.

Yeah, I don't think this is ideal, but it's not that bad either...

lldb/include/lldb/Target/TraceSessionFileParser.h
18

This would be better next to the definition of TraceThread class.

89–103

I don't understand the value of this function. Why couldn't the caller just call ParseProcesses(session.processes)?

Are you expecting this to grow and access other subfields of the session object? In that case, maybe it would be better for all JSONTraceSession<T>s to extend a common (non-templated) base class (JSONTraceSettingsBase?) and then this function could take a reference to that?

lldb/source/API/SystemInitializerFull.cpp
77

No terminate?

lldb/source/Plugins/Process/Trace/ProcessTrace.cpp
40

Maybe this should be just false? I don't think we'd ever want to create this object in response to a normal "launch" request...

wallace marked 4 inline comments as done.Oct 16 2020, 10:45 AM
wallace added inline comments.
lldb/source/Plugins/Process/Trace/ProcessTrace.cpp
40

This has to be plugin_specified_by_name, which means that this process plug-in is only used if explicitly invoked by plugin-name. A normal "launch" request would have plugin_specified_by_name as false

wallace updated this revision to Diff 298671.Oct 16 2020, 10:45 AM
wallace marked an inline comment as done.

Address all comments, including the renaming of the classes

wallace retitled this revision from [trace] rename ThreadIntelPT to TraceThread to [trace] rename ThreadIntelPT to ThreadTrace.Oct 16 2020, 10:46 AM
wallace edited the summary of this revision. (Show Details)
vsk added a subscriber: vsk.Oct 16 2020, 2:26 PM
vsk added inline comments.
lldb/include/lldb/Target/ThreadTrace.h
35

const FileSpec &, or just FileSpec might be better here.

35

What are the constraints on the format of "trace_file"? Is it a list of PC ranges?

wallace updated this revision to Diff 298766.Oct 16 2020, 2:44 PM

address comment

lldb/include/lldb/Target/ThreadTrace.h
35

The basic format is a JSON file with a schema specified in TraceSessionFileParser::BuildSchema

vsk added inline comments.Oct 16 2020, 2:56 PM
lldb/include/lldb/Target/ThreadTrace.h
35

Got it, thanks.

labath accepted this revision.Oct 19 2020, 3:11 AM
This revision is now accepted and ready to land.Oct 19 2020, 3:11 AM
clayborg accepted this revision.Oct 19 2020, 3:00 PM
This revision was landed with ongoing or failed builds.Oct 19 2020, 3:15 PM
This revision was automatically updated to reflect the committed changes.
lldb/source/Plugins/Process/Trace/ProcessTrace.cpp