[Lldb-commits] [PATCH] D88769: [trace] Scaffold "thread trace dump instructions"

[walter erquinigo via Phabricator via lldb-commits]

wallace added inline comments.


================
Comment at: lldb/source/Plugins/Process/Trace/ProcessTrace.h:18
+
+class ProcessTrace : public lldb_private::Process {
+public:
----------------
tatyana-krasnukha wrote:
> clayborg wrote:
> > So one issue is how do we eventually deal with debugging a live process that enables tracing. In that case we already have a real process class: ProcessGDBRemote most likely. We should avoid putting anything custom that is required from a process in this ProcessTrace class for when we actually have a real process class already. If we need to add anything, we will need to have virtual functions on the lldb_private::Process class that can call through to the Trace plug-in via its virtual functions as well to implement any functionality we might need.
> > 
> > Is this class solely going to be used for "trace load"?
> One option is to implement [[ https://sourceware.org/gdb/current/onlinedocs/gdb/Branch-Trace-Format.html | btrace ]] request in the ProcessGDBRemote and make remote stubs support it.
> 
> I'm also interested in live tracing for a custom process plugin which obtains instruction history in its own way. So, it would be good if a real process/thread provides data to the tracing plug-in.
Thanks @tatyana-krasnukha! I think I'll end up doing what you said. And definitely, step 2 of this project is to trace a live process.


================
Comment at: lldb/source/Plugins/Process/Trace/ProcessTrace.h:18
+
+class ProcessTrace : public lldb_private::Process {
+public:
----------------
wallace wrote:
> tatyana-krasnukha wrote:
> > clayborg wrote:
> > > So one issue is how do we eventually deal with debugging a live process that enables tracing. In that case we already have a real process class: ProcessGDBRemote most likely. We should avoid putting anything custom that is required from a process in this ProcessTrace class for when we actually have a real process class already. If we need to add anything, we will need to have virtual functions on the lldb_private::Process class that can call through to the Trace plug-in via its virtual functions as well to implement any functionality we might need.
> > > 
> > > Is this class solely going to be used for "trace load"?
> > One option is to implement [[ https://sourceware.org/gdb/current/onlinedocs/gdb/Branch-Trace-Format.html | btrace ]] request in the ProcessGDBRemote and make remote stubs support it.
> > 
> > I'm also interested in live tracing for a custom process plugin which obtains instruction history in its own way. So, it would be good if a real process/thread provides data to the tracing plug-in.
> Thanks @tatyana-krasnukha! I think I'll end up doing what you said. And definitely, step 2 of this project is to trace a live process.
Summarizing an offline conversation we had, we'd implement in this class only what is required for tracing a defunct process (i.e. from a json file). Otherwise, any trace logic should be in the main Process class, so that all trace plugins could reuse that logic. 

Also, during a live debugging session, we don't want to create a new Process object to hold the trace. We'll try to keep a single process to keep the architecture simple.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88769/new/

https://reviews.llvm.org/D88769