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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
