[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