[NFC][lldb][trace] Rename trace session to trace bundleAs previously discussed with @jj10306, we didn't really have a name forthe post-mortem (or offline) trace session representation, which is in
[NFC][lldb][trace] Rename trace session to trace bundleAs previously discussed with @jj10306, we didn't really have a name forthe post-mortem (or offline) trace session representation, which is infact a folder with a bunch of files. We decided to call this folder"trace bundle", and the main JSON file in it "trace bundle descriptionfile". This naming is pretty decent, so I'm refactoring all the existingcode to account for that.Differential Revision: https://reviews.llvm.org/D128484
show more ...
[trace][intelpt] Support system-wide tracing [12] - Support multi-core trace load and save:q!This diff is massive, but it's because it connects the client with lldb-serverand also ensures that th
[trace][intelpt] Support system-wide tracing [12] - Support multi-core trace load and save:q!This diff is massive, but it's because it connects the client with lldb-serverand also ensures that the postmortem case works.- Flatten the postmortem trace schema. The reason is that the schema has become quite complex due to the new multicore case, which defeats the original purpose of having a schema that could work for every trace plug-in. At this point, it's better that each trace plug-in defines it's own full schema. This means that the only common field is "type".-- Because of this new approach, I merged the "common" trace load and saving functionalities into the IntelPT one. This simplified the code quite a bit. If we eventually implement another trace plug-in, we can see then what we could reuse.-- The new schema, which is flattened, has now better comments and is parsed better. A change I did was to disallow hex addresses, because they are a bit error prone. I'm asking now to print the address in decimal.-- Renamed "intel" to "GenuineIntel" in the schema because that's what you see in /proc/cpuinfo.- Implemented reading the context switch trace data buffer. I had to dosome refactors to do that cleanly.-- A major change that I did here was to simplify the perf_event circular buffer reading logic. It was too complex. Maybe the original Intel author had something different in mind.- Implemented all the necessary bits to read trace.json files with per-core data.- Implemented all the necessary bits to save to disk per-core trace session.- Added a test that ensures that parsing and saving to disk works.Differential Revision: https://reviews.llvm.org/D126015
[trace][intel pt] Create a common accessor for live and postmortem dataSome parts of the code have to distinguish between live and postmortem threadsto figure out how to get some data, e.g. thread
[trace][intel pt] Create a common accessor for live and postmortem dataSome parts of the code have to distinguish between live and postmortem threadsto figure out how to get some data, e.g. thread trace buffers. This makes thecode less generic and more error prone. An example of that is that we havetwo different decoders: LiveThreadDecoder and PostMortemThreadDecoder. Theyexist because getting the trace bufer is different for each case.The problem doesn't stop there. Soon we'll have even more kinds of data, likethe context switch trace, whose fetching will be different for live and post-mortem processes.As a way to fix this, I'm creating a common API for accessing thread data,which is able to figure out how to handle the postmortem and live cases onbehalf of the caller. As a result of that, I was able to eliminate the twodecoders and unify them into a simpler one. Not only that, our TraceSavefunctionality only worked for live threads, but now it can also work forpostmortem processes, which might be useful now, but it might in the future.This common API is OnThreadBinaryDataRead. More information in the inlinedocumentation.Differential Revision: https://reviews.llvm.org/D123281
[trace] [intel pt] Create a "process trace save" commandadded new command "process trace save -d <directory>".-it saves a JSON file as <directory>/trace.json, with the main properties of the trace
[trace] [intel pt] Create a "process trace save" commandadded new command "process trace save -d <directory>".-it saves a JSON file as <directory>/trace.json, with the main properties of the trace session.-it saves binary Intel-pt trace as <directory>/thread_id.trace; each file saves each thread.-it saves modules to the directory <directory>/modules .-it only works for live process and it only support Intel-pt right now.Example:```b mainrunprocess trace startnprocess trace save -d /tmp/mytrace```A file named trace.json and xxx.trace should be generated in /tmp/mytrace. To load the trace that was just saved:```trace load /tmp/mytracethread trace dump instructions```You should see the instructions of the trace got printed.To run a test:```cd ~/llvm-sand/build/Release/fbcode-x86_64/toolchainninja lldb-dotest./bin/lldb-dotest -p TestTraceSave```Reviewed By: wallaceDifferential Revision: https://reviews.llvm.org/D107669
[LLDB] Move Trace-specific classes into separate libraryThese two classes, TraceSessionFileParser and ThreadPostMortemTrace,seem to be useful primarily for tracing. Currently it looks likeintel-p
[LLDB] Move Trace-specific classes into separate libraryThese two classes, TraceSessionFileParser and ThreadPostMortemTrace,seem to be useful primarily for tracing. Currently it looks likeintel-pt is the sole user of these, but that other tracing plugins couldbe written in the future that take advantage of these. Unfortunatelywith them in Target, there is a dependency on PluginProcessUtility. I'dlike to sever that dependency, so I moved them into a `TraceCommon`plugin.Differential Revision: https://reviews.llvm.org/D105649