This is an archive of the discontinued LLVM Phabricator instance.

[trace][intel pt] Create a class for the libipt decoder wrapper
ClosedPublic

Authored by wallace on Apr 4 2022, 11:22 PM.

Details

Summary

As we soon will need to decode multiple raw traces for the same thread,
having a class that encapsulates the decoding of a single raw trace is
a stepping stone that will make the coming features easier to implement.

So, I'm creating a LibiptDecoder class with that purpose. I refactored
the code and it's now much more readable. Besides that, more comments
were added. With this new structure, it's also easier to implement unit
tests.

Diff Detail

Event Timeline

wallace created this revision.Apr 4 2022, 11:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 4 2022, 11:22 PM
Herald added a subscriber: mgorny. · View Herald Transcript
wallace requested review of this revision.Apr 4 2022, 11:22 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 4 2022, 11:22 PM

Overall looks good, just a couple cosmetic things and comments about the plan for multi-buffer, single thread decoding

lldb/source/Plugins/Trace/intel-pt/LibiptDecoder.cpp
42

"for a single thread"
thinking ahead for the multi-CPU buffer case - this class will be responsible for decoding a single trace buffer, not necessarily a single thread's buffer, right? Also, come multi-buffer time, the notion of DecodeThread in this class will need to be changed to DecodedBuffer or something similar that decouples the decoder from a particular thread.

No need to change this now but wanted to make sure I'm understanding the plan correctly.

104
113
153
254

nice custom deleter (:

lldb/source/Plugins/Trace/intel-pt/LibiptDecoder.h
24

If this file is just a wrapper around Libipt and doesn’t have any context about how LLDB gets a trace (from the aux buffer or a file), should we rename it to ‘DecodeTrace’ and the caller is responsible for providing the trace data in a byte buffer?
In the case of in memory trace, the caller already has the byte buffer. In the case of a file, they could mmap the file and cast it to the appropriate type?

thanks for the gotchas

lldb/source/Plugins/Trace/intel-pt/LibiptDecoder.cpp
42

Also, come multi-buffer time, the notion of DecodeThread in this class will need to be changed to DecodedBuffer or something similar that decouples the decoder from a particular thread.

Not necessarily. A possibility is that the constructor doesn't accept a DecodedThread. Instead, we could create a new method DecodeUntilThreadIsScheduledOut(decoded_thread, end_tsc_for_this_thread). If we have something like that, we ask this decoder to put all the instructions into the given DecodedThread until a TSC mark is reached, which signals the end of a continuous execution of this thread.

lldb/source/Plugins/Trace/intel-pt/LibiptDecoder.h
24

DecodeTrace is definitely a better name because now we are not showing anymore whether the data comes from a file or just from memory

wallace updated this revision to Diff 421283.Apr 7 2022, 10:48 AM
wallace marked 6 inline comments as done.

address comments

jj10306 accepted this revision.Apr 7 2022, 3:43 PM
This revision is now accepted and ready to land.Apr 7 2022, 3:43 PM
lldb/source/Plugins/Trace/intel-pt/DecodedThread.cpp