[lldb-dev] Review of API and remote packets

[Ravitheja Addepally via lldb-dev]

Hello all,
              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 ->

lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const
SBTraceConfig &config)
    Start tracing for thread - threadId with trace configuration config.
    SBTraceConfig would contain the following fields-
            -> TraceType - ProcessorTrace, SoftwareTrace , any trace
technology etc
            -> size of trace buffer
            -> size of meta data buffer
    Returns error in case starting trace was unsuccessful, which could
occur by reasons such as
    picking non existent thread, target does not support TraceType selected
etc.

lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)
    Stop tracing for thread - threadId. Tracing should be enabled already
for thread, else error is returned.


size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
    Dump the raw trace data for threadId in buffer described by pointer buf
and size. Tracing should be enabled already for thread else error
    is sent in sberror. The actual size of filled buffer is returned by API.

size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t
size, SBError &sberror)
    Dump the raw trace meta data for threadId in buffer described by
pointer buf and size. Tracing should be enabled already for thread
    else error is sent in sberror. The actual size of filled buffer is
returned by API.


LLDB Trace Packet Specification

QTrace:1:<threadid>,<type>,<buffersize>,<metabuffersize>
    Packet for starting tracing, where -
        -> threadid - stands for thread to trace
        -> type -   Type of tracing to use, it will be like type of trace
mechanism to use.
                    For e.g ProcessorTrace, SoftwareTrace , any trace
technology etc and if
                    that trace is not supported by target error will be
returned. In Future
                    we can also add more parameters in the packet
specification, which can be type specific
                    and the server can parse them based on what type it
read in the beginning.
        -> buffersize - Size for trace buffer
        -> metabuffersize - Size of Meta Data

QTrace:0:<threadid>
    Stop tracing thread with threadid,{Trace needs to be started of-course
else error}

qXfer:trace:buffer:read:annex:<threadid>,<byte_count>
    Packet for reading the trace buffer
        -> threadid - thread ID, of-course if tracing is not
                        started for this thread error will be returned.
        -> byte_count - number of bytes to read, in case trace captured is
                        less than byte_count, then only that much trace will
                        be returned in response packet.

qXfer:trace:meta:read:annex:<threadid>,<byte_count>
    Similar Packet as above except it reads meta data
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160331/11000c26/attachment-0001.html>