<div dir="ltr">Hello,<div> Ok for the thread id we may use this QThreadSuffixSupported extension but gdb packets also <b>don't have userid support </b>since gdb does not have the concept of user id for trace instances. Also gdb uses seperate packets for trace configuration and starting the trace.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 12:26 PM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">LLDB already has the QThreadSuffixSupported extension, which adds the<br>
";thread:<tid>" suffix to a bunch of packets. We could say that if the<br>
client requests this extension, we will support it on these packets as<br>
well. Otherwise we fall back to the "Hg" thingy.<br>
<br>
I haven't looked at how hard it would be to implement that...<br>
<span class="HOEnZb"><font color="#888888"><br>
pl<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 12 April 2016 at 09:01, Ravitheja Addepally <<a href="mailto:ravithejawork@gmail.com">ravithejawork@gmail.com</a>> wrote:<br>
> One of the downsides of using the gdb protocol is that these packets are<br>
> stateful meaning the thread id option is not there and the word btrace<br>
> stands for branch trace which basically suggests execution tracing.<br>
><br>
> On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br>
>><br>
>> I think we should reuse packets from the gdb protocol whereever it<br>
>> makes sense. So, if they fit your needs (and a quick glance seems to<br>
>> confirm that), then I think you should use them.<br>
>><br>
>> On 11 April 2016 at 15:28, Ravitheja Addepally <<a href="mailto:ravithejawork@gmail.com">ravithejawork@gmail.com</a>><br>
>> wrote:<br>
>> > Hello,<br>
>> > Regarding the packet definitions for tracing, how about reusing<br>
>> > the<br>
>> > existing btrace packets ?<br>
>> ><br>
>> ><br>
>> > <a href="https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read" rel="noreferrer" target="_blank">https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read</a><br>
>> ><br>
>> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
>> >><br>
>> >> We also need to think about all other types of tracing. It might make<br>
>> >> more<br>
>> >> sense to keep these calls on SBProcess and have the calls simply be:<br>
>> >><br>
>> >><br>
>> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions<br>
>> >> &trace_options,<br>
>> >> lldb::SBError &error);<br>
>> >><br>
>> >> And you would need to specify which threads in the SBTraceOptions<br>
>> >> object<br>
>> >> itself?:<br>
>> >><br>
>> >> SBTraceOptions trace_options;<br>
>> >><br>
>> >> And then do some like:<br>
>> >><br>
>> >> trace_options.SetTraceAllThreads();<br>
>> >><br>
>> >> And maybe tracing all threads is the default. Or one can limit this to<br>
>> >> one<br>
>> >> thread:<br>
>> >><br>
>> >> trace_options.SetThreadID (tid);<br>
>> >><br>
>> >> Then you start tracing using the "trace_options" which has the notion<br>
>> >> of<br>
>> >> which threads to trace.<br>
>> >><br>
>> >> lldb::SBError error;<br>
>> >> lldb::SBTrace trace = process.StartTrace(trace_options, error);<br>
>> >><br>
>> >> It really depends on how all different forms of trace are enabled for<br>
>> >> different kinds of tracing. It takes kernel support to trace only<br>
>> >> specific<br>
>> >> threads, but someone might be debugging a bare board that only has the<br>
>> >> option tracing all threads on each core. When making an API we can't<br>
>> >> assume<br>
>> >> we can limit this to any threads and even to any process.<br>
>> >><br>
>> >> Greg<br>
>> >><br>
>> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br>
>> >> ><br>
>> >> > I second Greg's suggestions, and I have some thoughts of my own:<br>
>> >> ><br>
>> >> > - with the proposed API, it is not possible to get a trace for newly<br>
>> >> > created threads - the process needs to be stopped first, so you can<br>
>> >> > enable trace collection. There certainly are cases where this could<br>
>> >> > be<br>
>> >> > problematic, e.g. if you get a crash early during thread creation and<br>
>> >> > you want to figure out how you got there. For this to work, we might<br>
>> >> > need an API like<br>
>> >> > SBProcess::TraceNewThreads(...)<br>
>> >> > or<br>
>> >> > SBProcess::TraceAllThreads(...)<br>
>> >> > with the assumption that "all" also includes newly created threads in<br>
>> >> > the future.<br>
>> >> ><br>
>> >> > I'm not saying this needs to be done in the first implementation, but<br>
>> >> > I think that we should at least design the API in a way that will not<br>
>> >> > make adding this unnecessarily hard in the future (e.g. the idea of<br>
>> >> > returning an SBTrace object might be problematic, since you don't<br>
>> >> > know<br>
>> >> > if/how many threads will be created).<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > Also, thinking about new APIs, should we have a way to mark an API as<br>
>> >> > incubating/experimental? Maybe it would be good to mark these new<br>
>> >> > APIs<br>
>> >> > as experimental for a while, so we have an option of changing them in<br>
>> >> > the future, if it turns out we have made the wrong decision. I was<br>
>> >> > thinking of either a naming convention<br>
>> >> > (SBThread::StartTraceExperimental) or some annotation/comment on the<br>
>> >> > methods. When we are confident this design is good, we can remove the<br>
>> >> > promote the api into the "stable" set.<br>
>> >> ><br>
>> >> > pl<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev<br>
>> >> > <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
>> >> >><br>
>> >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev<br>
>> >> >>> <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
>> >> >>><br>
>> >> >>> Hello all,<br>
>> >> >>> I am currently working on enabling Intel (R) Processor<br>
>> >> >>> Trace collection for lldb. I have done some previous discussions in<br>
>> >> >>> this<br>
>> >> >>> mailing list on this topic but just to summarize , the path we<br>
>> >> >>> chose was to<br>
>> >> >>> implement raw trace collection in lldb and the trace will be<br>
>> >> >>> decoded outside<br>
>> >> >>> LLDB. I wanted to expose this feature through the SB API's and for<br>
>> >> >>> trace<br>
>> >> >>> data transfer I wish to develop new communication packets. Now I<br>
>> >> >>> want to get<br>
>> >> >>> the new API's and packet specifications reviewed by the dev list.<br>
>> >> >>> Please<br>
>> >> >>> find the specification below -><br>
>> >> >>><br>
>> >> >>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const<br>
>> >> >>> SBTraceConfig &config)<br>
>> >> >>> Start tracing for thread - threadId with trace configuration<br>
>> >> >>> config.<br>
>> >> >>> SBTraceConfig would contain the following fields-<br>
>> >> >>> -> TraceType - ProcessorTrace, SoftwareTrace , any trace<br>
>> >> >>> technology etc<br>
>> >> >>> -> size of trace buffer<br>
>> >> >>> -> size of meta data buffer<br>
>> >> >>> Returns error in case starting trace was unsuccessful, which<br>
>> >> >>> could<br>
>> >> >>> occur by reasons such as<br>
>> >> >>> picking non existent thread, target does not support TraceType<br>
>> >> >>> selected etc.<br>
>> >> >><br>
>> >> >> If you are going to trace on a thread, we should be putting this API<br>
>> >> >> on<br>
>> >> >> SBThread. Also we have other config type classes in our public API<br>
>> >> >> and we<br>
>> >> >> have suffixed them with Options so SBTraceConfig should actually be<br>
>> >> >> SBTraceOptions. Also don't bother using "const" on any public APIs<br>
>> >> >> since the<br>
>> >> >> mean nothing and only cause issues. Why? All public classes usually<br>
>> >> >> contain<br>
>> >> >> a std::unique_ptr or a std::shared_ptr to a private class that<br>
>> >> >> exists only<br>
>> >> >> within LLDB itself. The "const" is just saying don't change my<br>
>> >> >> shared<br>
>> >> >> pointer, which doesn't actually do anything.<br>
>> >> >><br>
>> >> >> lldb::SBError SBThread::StartTrace(SBTraceOptions &trace_options);<br>
>> >> >><br>
>> >> >>><br>
>> >> >>> lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId)<br>
>> >> >>> Stop tracing for thread - threadId. Tracing should be enabled<br>
>> >> >>> already for thread, else error is returned.<br>
>> >> >><br>
>> >> >> This should be:<br>
>> >> >><br>
>> >> >> lldb::SBError SBThread::StopTrace();<br>
>> >> >><br>
>> >> >> One question: can there only be one kind of trace going on at the<br>
>> >> >> same<br>
>> >> >> time? If we ever desire to support more than one at a time, we might<br>
>> >> >> need<br>
>> >> >> the above two calls to be:<br>
>> >> >><br>
>> >> >><br>
>> >> >> lldb::user_id_t SBThread::StartTrace(SBTraceOptions &trace_options,<br>
>> >> >> lldb::SBError &error);<br>
>> >> >> lldb::SBError SBThread::StopTrace(lldb::user_id_t trace_id);<br>
>> >> >><br>
>> >> >> The StartTrace could return a unique trace token that would need to<br>
>> >> >> be<br>
>> >> >> supplied back to any other trace calls like the ones below.<br>
>> >> >><br>
>> >> >>> size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf,<br>
>> >> >>> size_t size, SBError &sberror)<br>
>> >> >>> Dump the raw trace data for threadId in buffer described by<br>
>> >> >>> pointer<br>
>> >> >>> buf and size. Tracing should be enabled already for thread else<br>
>> >> >>> error<br>
>> >> >>> is sent in sberror. The actual size of filled buffer is returned<br>
>> >> >>> by<br>
>> >> >>> API.<br>
>> >> >>><br>
>> >> >>> size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void<br>
>> >> >>> *buf,<br>
>> >> >>> size_t size, SBError &sberror)<br>
>> >> >>> Dump the raw trace meta data for threadId in buffer described by<br>
>> >> >>> pointer buf and size. Tracing should be enabled already for thread<br>
>> >> >>> else error is sent in sberror. The actual size of filled buffer<br>
>> >> >>> is<br>
>> >> >>> returned by API.<br>
>> >> >><br>
>> >> >> These would be on lldb::SBThread and remove the lldb::tid_t<br>
>> >> >> parameter,<br>
>> >> >> possibly adding "lldb::user_id_t trace_id" as the first parameter.<br>
>> >> >><br>
>> >> >> The other way to do this is to create a lldb::SBTrace object. Then<br>
>> >> >> the<br>
>> >> >> APIs become:<br>
>> >> >><br>
>> >> >> lldb::SBTrace SBThread::StartTrace(SBTraceOptions &trace_options,<br>
>> >> >> lldb::SBError &error);<br>
>> >> >><br>
>> >> >> lldb::SBError SBTrace::StopTrace();<br>
>> >> >> size_t SBTrace::GetData(void *buf, size_t size, SBError &sberror);<br>
>> >> >> size_t SBTrace::GetMetaData(void *buf, size_t size, SBError<br>
>> >> >> &sberror);<br>
>> >> >> lldb::SBThread SBTrace::GetThread();<br>
>> >> >><br>
>> >> >>><br>
>> >> >>> LLDB Trace Packet Specification<br>
>> >> >>><br>
>> >> >>> QTrace:1:<threadid>,<type>,<buffersize>,<metabuffersize><br>
>> >> >>> Packet for starting tracing, where -<br>
>> >> >>> -> threadid - stands for thread to trace<br>
>> >> >>> -> type - Type of tracing to use, it will be like type of<br>
>> >> >>> trace mechanism to use.<br>
>> >> >>> For e.g ProcessorTrace, SoftwareTrace , any<br>
>> >> >>> trace<br>
>> >> >>> technology etc and if<br>
>> >> >>> that trace is not supported by target error will<br>
>> >> >>> be<br>
>> >> >>> returned. In Future<br>
>> >> >>> we can also add more parameters in the packet<br>
>> >> >>> specification, which can be type specific<br>
>> >> >>> and the server can parse them based on what type<br>
>> >> >>> it<br>
>> >> >>> read in the beginning.<br>
>> >> >>> -> buffersize - Size for trace buffer<br>
>> >> >>> -> metabuffersize - Size of Meta Data<br>
>> >> >><br>
>> >> >> If we design this, we should have the arguments be in key/value<br>
>> >> >> format:<br>
>> >> >><br>
>> >> >>> QTrace:1:<key>:<value>;<key>:<value>;<key>:<value>;<br>
>> >> >><br>
>> >> >> Then this packet currently could be sent as:<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> QTrace:1:threadid:<threadid>;type:<type>;buffersize=<buffersize>;metabuffersize=<metabuffersize>;<br>
>> >> >><br>
>> >> >> This way if we ever need to add new key value pairs, we don't need<br>
>> >> >> to<br>
>> >> >> make a new QTrace2 packet if the args ever change.<br>
>> >> >><br>
>> >> >><br>
>> >> >>> QTrace:0:<threadid><br>
>> >> >>> Stop tracing thread with threadid,{Trace needs to be started<br>
>> >> >>> of-course else error}<br>
>> >> >><br>
>> >> >> again, this should be key/value pair encoded<br>
>> >> >><br>
>> >> >> QTrace:0:threadid:<threadid>;<br>
>> >> >>><br>
>> >> >>> qXfer:trace:buffer:read:annex:<threadid>,<byte_count><br>
>> >> >>> Packet for reading the trace buffer<br>
>> >> >>> -> threadid - thread ID, of-course if tracing is not<br>
>> >> >>> started for this thread error will be<br>
>> >> >>> returned.<br>
>> >> >>> -> byte_count - number of bytes to read, in case trace<br>
>> >> >>> captured<br>
>> >> >>> is<br>
>> >> >>> less than byte_count, then only that much<br>
>> >> >>> trace<br>
>> >> >>> will<br>
>> >> >>> be returned in response packet.<br>
>> >> >>><br>
>> >> >>> qXfer:trace:meta:read:annex:<threadid>,<byte_count><br>
>> >> >>> Similar Packet as above except it reads meta data<br>
>> >> >><br>
>> >> >> Hopefully we can key/value pair encode the args text that is<br>
>> >> >> "<threadid>,<byte_count>".<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> _______________________________________________<br>
>> >> >> lldb-dev mailing list<br>
>> >> >> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
>> >> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>