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

[Greg Clayton via lldb-dev]

> On Oct 2, 2020, at 3:51 AM, Pavel Labath <pavel at labath.sk> wrote:
> 
> On 01/10/2020 22:32, Walter wrote:
>> After a chat with Greg, we agreed on this set of commands
>> 
>> 
>> trace load /path/to/json process trace start/stop process trace save
>> /path/to/json thread trace start/stop thread trace dump [instructions |
>> functions]
>> 
> 
> Thanks. The new commands look good to me.

Great, we can move the "trace dump" over to "thread trace dump" for https://reviews.llvm.org/D86670 <https://reviews.llvm.org/D86670> and keep that moving.

> The multi-process trace concept is interesting. I don't question its
> usefulness -- I am sure it can be useful for various kinds of analysis
> (though I've never used that myself). I am wondering though about how to
> represent this thing in lldb, as we don't really have anything close to
> the concept of "debugging" all processes on a given system.
> 
> The only thing that comes close is probably the kernel-level debugging.
> One idea (which has just occurred to me, so it may not be good) might be
> to make these traces behave similarly to that. I.e., create a single
> target/process with one "thread" per physical cpu, and then have a
> special "os plugin" like thing which would present individual
> process/threads.

I don't know enough about how trace data is stored or annotated after the raw data is pulled from the cores, but to make it useful it must be able to be associated with processes and threads somehow otherwise it would be just a bunch of addresses that would all overlap between many processes. 

 
> That would have the advantage of maintaining the one trace-one target
> invariant and also would preserve the information about relative timings
> of individual "processes". I think that wuold be an interesting way to
> view these things, but I don't know if it would be the best one...

I might suggest that each trace plug-in should do its best to represent processes and threads as separate entities so that they all remain separate. What ever data starts out as should be abstracted and I think I would rather see individual processes with their threads if that is possible to do, but I am just thinking of this with just a bit of knowledge tracing data. I think many chip makers create these trace formats and they are designed from a "trace a core" perspective, but if we can tame this data and present it as users would want to see it instead of trying to represent it as the data is stored, I think we will have a compelling trace feature in our debugger.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20201002/ec8c47fb/attachment.html>