[Lldb-commits] [PATCH] D89408: [trace] rename ThreadIntelPT to TraceThread
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Fri Oct 16 04:45:59 PDT 2020
labath added a comment.
In D89408#2333502 <https://reviews.llvm.org/D89408#2333502>, @wallace wrote:
> 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...
================
Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:18
+typedef std::shared_ptr<TraceThread> TraceThreadSP;
+
----------------
This would be better next to the definition of TraceThread class.
================
Comment at: lldb/include/lldb/Target/TraceSessionFileParser.h:87-101
+ /// Parse the fields common to all trace session schemas.
+ ///
+ /// \param[in] session
+ /// The session json objects already deserialized.
+ ///
+ /// \return
+ //// A list of \a ParsedProcess containing all threads and targets created
----------------
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?
================
Comment at: lldb/source/API/SystemInitializerFull.cpp:74
// Now shutdown the common parts, in reverse order.
SystemInitializerCommon::Terminate();
----------------
No terminate?
================
Comment at: lldb/source/Target/TraceProcess.cpp:40
+bool TraceProcess::CanDebug(TargetSP target_sp, bool plugin_specified_by_name) {
return plugin_specified_by_name;
}
----------------
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...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D89408/new/
https://reviews.llvm.org/D89408
More information about the lldb-commits
mailing list