<div dir="ltr">Hi Everyone<div><br></div><div>I have developed a tool that facilitates lldb users using Intel(R) Processor Trace technology for debugging applications (as per discussions in this thread). The patch is <a href="https://reviews.llvm.org/D33035">https://reviews.llvm.org/D33035</a>.</div><div><br></div><div>Some highlights of this tool are:</div><div>1. The tool is built on top of lldb. It is not a part of liblldb shared library. It resides in tool/intel-features folder. Anyone willing to use this feature can compile this tool (by enabling some extra flags) using cmake while building lldb.</div><div>2. As it was suggested, the trace decoding library hasn't been made a part of lldb repository. It can be downloaded from the corresponding github repo.</div><div>3. All intel specific features are combined to form single shared library thereby not cluttering lldb repository with each intel specific feature (proposed by Pavel).</div><div><br></div><div>If something has changed or you have new concerns regarding this tool since the last discussion in this thread, please let me know.</div><div><br></div><div>- Abhishek</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 4:38 PM, Abhishek Aggarwal <span dir="ltr"><<a href="mailto:abhiinnitald@gmail.com" target="_blank">abhiinnitald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Greg<br><br>Please find any answers/queries inlined:<span class=""><br><br>On Thu, Feb 4, 2016 at 9:58 PM, Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>><br>>> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>>><br>>> On 4 February 2016 at 10:04, Ravitheja Addepally<br>>> <<a href="mailto:ravithejawork@gmail.com" target="_blank">ravithejawork@gmail.com</a>> wrote:<br>>>> Hello Pavel,<br>>>>                In the case of expression evaluation approach you mentioned<br>>>> that:<br>>>> 1. The data could be accessible only when the target is stopped. why is that<br>>>> ?<br>>> If I understand the approach correctly, the idea is the run all perf<br>>> calls as expressions in the debugger. Something like<br>>> lldb> expr perf_event_open(...)<br>>> We need to stop the target to be able to do something like that, as we<br>>> need to fiddle with its registers. I don't see any way around that...<br>>><br>>>> 2. What sort of noise were you referring to ?<br>>> Since now all the perf calls will be expressions executed within the<br>>> context of the process being traced, they themselves will show up in<br>>> the trace. I am sure we could filter that out somehow, but it feels<br>>> like an added complication..<br>>><br>>> Does that make it any clearer?<br>><br>> So a few questions: people seem worried about running something in the process if expression are being used. Are you saying that if the process is on the local machine, process 1 can just open up a file descriptor to the trace data for process 2? If so, why pass this through lldb-server?<br><br></span><font color="#ff0000">As you have also mentioned later in your email, irrespective of what approach we use to implement this feature, we will have to send the trace data from lldb-server to client in case of remote debugging. Moreover even for local debugging, the current architecture of lldb is a client-server architecture (atleast for macosx, linux and freebsd) as per my knowledge. Hence, traces will have to be sent </font><span style="color:rgb(255,0,0)">in form of packets </span><font color="#ff0000">from server </font><span style="color:rgb(255,0,0)">to client </span><font color="#ff0000">even for the expression evaluation approach. </font><span class=""><br><br>> I am not a big fan making the lldb-server become the conduits for a ton of information. It just isn't built for that high volumes of data coming in. I can be done, but that doesn't mean it should.  If everyone starts passing data like memory usage, CPU time, trace info, backtraces and more through asynchronously through lldb-server, it will become a very crowded communication channel.<br>></span><div><span style="color:rgb(255,0,0)">As per my understanding, one of the difference the expression evaluation approach provides is to disallow sending traces from server to client asynchronously (as traces can't be sent until inferior stops). If increased number of asynchronous packets are the concern here then we can choose to send the trace data only synchronously (i.e. only after the inferior stops). Or can't we ?</span></div><span class=""><div><font color="#ff0000"><br></font>> You don't need python if you want to do this using the lldb API. If your IDE is already linking against the LLDB shared library, it can just run the expressions using the public LLDB API. This is how view debugging is implemented in Xcode. It runs complex expressions that gather all data about a view and its subviews and returns all the layers in a blob of data that can be serialized by the expression, retrieved by Xcode (memory read from the process), and then de-serialized by the IDE into a format that can be used. If your IDE can access the trace data for another process, why not just read it from the IDE itself? Why get the lldb-server involved? Granted the remote debugging parts of this make an argument for including it in the lldb-server. But if you go this route you need to make a base implementation for trace data that will work for any trace data, have trace data plug-ins that somehow know how to interpret the data and provide.<br>></div></span><div><span style="color:rgb(255,0,0)">Thanks for suggesting this. </span></div><span class=""><div><font color="#ff0000"><br></font>> How do you say "here is a blob of trace data" I just got from some process, go find me a plug-in that can parse it. You might have to say "here is a blob of data" and it is for the "intel" trace data plug-in. How are we going to know which trace data to ask for? Is the packet we send to lldb-server going to reply to "qGetTraceData" with something that says the type of data is "intel-IEEE-version-123.3.1" and the data is "xxxxxxx"? Then we would find a plug-in in LLDB for that trace data that can parse it? So you will need to think about completely abstracting the whole notion of trace data into some sensible API that gets exposed via SBProcess.<br>></div></span><div><font color="#ff0000">We need to think a bit more on this.</font></div><span class=""><div><font color="#ff0000"><br></font>> So yes, there are two approaches to take. Let me know which one is the way you want to go. But I really want to avoid the GDB remote protocol's async packets becoming the conduit for a boat load of information.<br>></div></span><div><font color="#ff0000">In order to configure/start/finish the tracing feature, a lot of expression evaluations will have to be done (atleast </font><span style="color:rgb(255,0,0)">perf_event_open(), mmap(), perf_event_close() are the ones I know of</span>). <font color="#ff0000">The main reason I am skeptical of expression evaluation approach is the amount of extra packets to be sent to the lldb-server to configure/start/finish tracing. Hence, I am more in favor of w</font><span style="color:rgb(255,0,0)">riting the code to configure/start/finish the tracing on lldb-server side. Once we have all the traces with us and inferior stops, we can send them only synchronously over the communication channel.</span></div><div><span style="color:rgb(255,0,0)"><br></span></div><div><span style="color:rgb(255,0,0)">Please correct me if I there is something wrong with my understanding. Thanks a lot for your detailed email.</span></div><span class=""><div><br></div><div>> Greg Clayton<br>><br>><br>> ______________________________<wbr>_________________<br>> lldb-dev mailing list<br>> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br></div><div><br></div></span><span class="HOEnZb"><font color="#888888"><div>- Abhishek</div></font></span></div>
</blockquote></div><br></div>