[Lldb-commits] [PATCH] D29581: Initial implementation of SB APIs for Tracing support.
Ravitheja Addepally via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Fri Mar 10 02:27:41 PST 2017
ravitheja added inline comments.
================
Comment at: scripts/interface/SBTrace.i:12
+
+class LLDB_API SBTrace {
+public:
----------------
clayborg wrote:
> Do we want something in here that explains what kind of trace buffer data you will be getting? I am thinking that even though we know we ask for "eTraceTypeProcessorTrace", this might not be enough for a plug-in to interpret these bytes. Do we need something like:
>
> ```
> class SBTrace {
> const char *GetTraceDataName();
> };
> ```
>
> And for intel it might return "intel processor trace version 2.0"? Or Maybe it would. be better as:
>
> ```
> class SBTrace {
> lldb::SBStructuredData GetTraceDataInfo();
> };
> ```
>
> This could return data that could be accessed as JSON. The version could be encoded in here. Maybe the exact CPU type, or CPU ID could also be encoded. I am guessing that the intel processor trace has already changed format from CPU to CPU and might also change in the future? This would help the plug-in that will interpret the trace byte to extract them correctly?
Hello, Couldn't this be done in the GetTraceConfig (currently I am doing this) , as the TraceOptions already has a StructuredData for custom parameters and configurations, any trace technology could just convey any special or trace specific configurations in the custom parameters of TraceOptions ?
https://reviews.llvm.org/D29581
More information about the lldb-commits
mailing list