[Lldb-commits] [PATCH] D91679: [trace][intel-pt] Implement trace start and trace stop
Greg Clayton via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Tue Mar 30 17:02:25 PDT 2021
clayborg added a comment.
Looking really good.
See inline comments about the need for a ProcessorTraceStopReason.
Since we have the eStopReasonProcessorTrace stop reason now, we should probably deliver these stops to the Trace plug-in so that it can respond maybe? Fine if we can to do this in another patch.
================
Comment at: lldb/include/lldb/Target/StopInfo.h:133
+ static lldb::StopInfoSP
+ CreateStopReasonProcessorTrace(Thread &thread, const char *description);
+
----------------
Do we need an extra enumeration for eStopReasonProcessorTrace that we would add as a parameter? I could think of:
```
enum ProcessorTraceStopReason {
///< Max memory for process has been exceeded (current patch and the only reason we stop with eStopReasonProcessorTrace , right?)
eProcessorTraceProcessBufferFull = 1
///< For using a buffer that fills and then stops the process (future patch)
eProcessorTraceThreadBufferFull,
///< For when tracing specific threads and all threads that were traced have exited (future patch)
eProcessorTraceTraceEnded,
eProcessorTraceXXXX
};
```
Then this data could be return from SBThread APIs via:
```
size_t SBThread::GetStopReasonDataCount();
uint64_t SBThread::GetStopReasonDataAtIndex(uint32_t idx);
```
Where SBThread::GetStopReasonDataCount() would return 1, and SBThread::GetStopReasonDataAtIndex(0) would return this enumeration. We would also use this enumeration in the Trace plug-ins when responding to stops that were eStopReasonProcessorTrace
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91679/new/
https://reviews.llvm.org/D91679
More information about the lldb-commits
mailing list