<div dir="ltr">Hello all,<div>              I am currently working on enabling Intel (R) Processor Trace collection for lldb. I have done some previous discussions in this mailing list on this topic but just to summarize , the path we chose was to implement raw trace collection in lldb and the trace will be decoded outside LLDB. I wanted to expose this feature through the SB API's  and for trace data transfer I wish to develop new communication packets. Now I want to get the new API's and packet specifications reviewed by the dev list. Please find the specification below -></div><div><br></div><div><div>lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const SBTraceConfig &config)</div><div>    Start tracing for thread - threadId with trace configuration config.</div><div>    SBTraceConfig would contain the following fields-</div><div>            -> TraceType - ProcessorTrace, SoftwareTrace , any trace technology etc</div><div>            -> size of trace buffer</div><div>            -> size of meta data buffer</div><div>    Returns error in case starting trace was unsuccessful, which could occur by reasons such as</div><div>    picking non existent thread, target does not support TraceType selected etc.</div><div><br></div><div>lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)</div><div>    Stop tracing for thread - threadId. Tracing should be enabled already for thread, else error is returned.</div><div><br></div><div><br></div><div>size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t size, SBError &sberror)</div><div>    Dump the raw trace data for threadId in buffer described by pointer buf and size. Tracing should be enabled already for thread else error</div><div>    is sent in sberror. The actual size of filled buffer is returned by API.</div><div><br></div><div>size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t size, SBError &sberror)</div><div>    Dump the raw trace meta data for threadId in buffer described by pointer buf and size. Tracing should be enabled already for thread </div><div>    else error is sent in sberror. The actual size of filled buffer is returned by API.</div><div><br></div><div><br></div><div>LLDB Trace Packet Specification</div><div><br></div><div><div>QTrace:1:<threadid>,<type>,<buffersize>,<metabuffersize></div><div>    Packet for starting tracing, where -</div><div>        -> threadid - stands for thread to trace</div><div>        -> type -   Type of tracing to use, it will be like type of trace mechanism to use.</div><div>                    For e.g ProcessorTrace, SoftwareTrace , any trace technology etc and if </div><div>                    that trace is not supported by target error will be returned. In Future</div><div>                    we can also add more parameters in the packet specification, which can be type specific </div><div>                    and the server can parse them based on what type it read in the beginning.</div><div>        -> buffersize - Size for trace buffer</div><div>        -> metabuffersize - Size of Meta Data</div><div><br></div><div>QTrace:0:<threadid></div><div>    Stop tracing thread with threadid,{Trace needs to be started of-course else error}</div><div><br></div><div>qXfer:trace:buffer:read:annex:<threadid>,<byte_count></div><div>    Packet for reading the trace buffer</div><div>        -> threadid - thread ID, of-course if tracing is not</div><div>                        started for this thread error will be returned.</div><div>        -> byte_count - number of bytes to read, in case trace captured is</div><div>                        less than byte_count, then only that much trace will</div><div>                        be returned in response packet.</div><div><br></div><div>qXfer:trace:meta:read:annex:<threadid>,<byte_count></div><div>    Similar Packet as above except it reads meta data</div></div></div></div>