[lldb-dev] RFC: Processor Trace Support in LLDB

[Greg Clayton via lldb-dev]

> On Oct 1, 2020, at 7:08 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Thank you for writing this Walter. I think this document will be a
> useful reference both now and in the future.
> 
> The part that's not clear to me is what is the story with multi-process
> traces. The file format enables those, but it's not clear how are they
> going be created or used. Can you elaborate more on what you intend to
> use those for?

Mainly for system trace kinds of things where an entire system gets traced.

> 
> The main reason I am asking that is because I am thinking about the
> proposed command structure. I'm wondering if it would not be better to
> fit this into the existing target/process/thread commands instead of
> adding a new top-level command. For example, one could imagine the
> following set of commands:
> 
> - "process trace start" + "thread trace start" instead of "thread trace
> [tid]". That would be similar to "process continue" + "thread continue".
> - "thread trace dump [tid]" instead of "trace dump [-t tid]". That would
> be similar to "thread continue" and other thread control commands.
> - "target create --trace" instead of "trace load". (analogous to target
> create --core).
> - "process trace save" instead of "trace save" -- (mostly) analogous to
> "process save-core"

> I am thinking this composition may fit in better into the existing lldb
> command landscape, though I also see the appeal in grouping everything
> trace-related under a single top-level command. What do you think?
> 
> The main place where this idea breaks down is the multi-process traces.
> While we could certainly make "target create --trace" create multiple
> targets, that would be fairly unusual. OTOH, the whole concept of having
> multiple targets share something is a pretty unusual thing for lldb.
> That's why I'd like to hear more about where you want to go with this idea.

I kind of see tracing has having two sides:
1 - post mortem tracing for individual or multiple processes
2 - live debug session tracing for being able to see how you crashed where trace data is for current process only

For post mortem tracing, the trace top level command seemed to make sense here because there are no other target commands that act on more than one target. So "trace load" makes sense to me here for loading one or more traces. The idea is the trace JSON file has enough info to completely load up the state of the trace so we can symbolicate, dump and step around in history. So I would vote to keep "trace load" at the very least because it can create one or more targets. Options can be added to display the processes if needed:

(lldb) trace list <trace-json-file>

But we could move "trace dump" over into "target trace dump" or "process trace dump" since that is effectively how we are coding these patches.

For live debugging where we gather trace data through the process plug-in, we will have a live process that may or may not have trace data. If tracing isn't available we will not be able to dump anything. But I would like to see process/thread commands for this scenario:

- process trace start/stop (only succeeds if we can gather trace data through the process plug-in)
- thread trace start/stop (which can succeed only if current tracing can enable tracing for only one thread)

Not sure if we need "process trace save" or "thread trace save" as the saving can be done as an option to "process trace stop --save /path/to/save"

So I am all for fitting these commands in where they need to go.

> 
> On 21/09/2020 22:17, Walter via lldb-dev wrote:
>> Thanks for your feedback Fangrui, I've just been checking Capn' Proto
>> and it looks really good. I'll keep it in mind in the design and see how
>> it can optimize the overall data transfer.
> 
> I'm not sure how Cap'n Proto comes into play here. The way I understand
> it, the real data is contained in a separate file in the specialized
> intel format and the json is just for the metadata. I'd expect the
> metadata file to be small even for enormous traces, so I'm not sure
> what's to be gained by optimizing it.
> 
> pl
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev