<div dir="ltr">Thanks for your comments, I'll reply here:<div><br></div><div><div><div>> Is it possible to decode a small portion of an Intel PT trace file quickly, say, in a few milliseconds? This would be useful if tracing were done in ringbuffer mode, or if the event the user is interested in debugging (along with its relevant execution history) is known to occur at the end of the trace. The user could potentially choose which subset of the trace to decode, and re-decode a different subset if more context is needed.</div><span class="gmail-im" style="color:rgb(80,0,80)"><div><br></div><div>Yes, it's totally possible. I'll dig a little deep into the Intel PT trace structure. A trace is made of a bunch of packets, where some are synchronization packets (PSB packets). You can pick an arbitrarily sync packet, and from that point on start decoding. This means that it's possible to decode backwards (i.e. find the last sync packet, decode the packets up to the end of the trace, then move to the previous sync packet, decode until the former packet, and so on). This is very valuable and I'll keep it in mind for the implementation.</div><div><br></div></span>> What mechanisms are available for discerning the root cause of a gap? Does the Intel PT decoder have internal consistency checks that can diagnose hardware bugs (or decoder bugs, for that matter)?</div><div><br></div><div>Yes. Whenever there's a decoding error, the libipt decoder notifies us of what the error is. You can check the DecodeInstructions function in <a href="https://reviews.llvm.org/D87589">https://reviews.llvm.org/D87589</a> if you are interested, although it's not a light read.</div><div><br></div><div>> Also, when a gap occurs, perhaps it's possible that the instructions leading up to the gap are not accurate. E.g., if the decoding process desyncs from the trace file while disassembling, it's possible to accidentally follow (or ignore) a branch. Are there measures to detect/erase those inaccurate instructions prior to a gap?</div><div><br></div><div>I don't think this can happen. When an instruction can't be decoded, the decoder moves to the next synchronization point and resumes decoding from that point. Interestingly, it's possible to configure how often synchronization packets are produced. IIRC you could even request one sync packet per CPU cycle, leading to small gaps. If this configuration is not specified, the CPU itself decides when to produce these packets, which tend to be every few KB of data.</div><div><br></div><div>> Also, how should a gap be represented in the debugger output? E.g., if a gap is encountered while dumping instructions, should the debugger print <gap: instruction unknown>?</div><div><div><div class="gmail-adm" style="margin:5px 0px"><div id="gmail-q_431" class="gmail-ajR gmail-h4" style="background-color:rgb(232,234,237);border:none;clear:both;line-height:6px;outline:none;width:24px;color:rgb(80,0,80);font-size:11px;border-radius:5.5px"><div class="gmail-ajT" style="background:url("https://www.gstatic.com/images/icons/material/system/1x/more_horiz_black_20dp.png") 50% 50%/20px no-repeat;height:11px;opacity:0.54;width:24px"></div></div></div></div><div>Imho it's important to nail down a user interface metaphor for navigating/exploring a trace before adding any 'dump'-like commands. I don't think we've done that yet.</div><div><br></div><div>We definitely should let the user know of these events. When dumping traces in this WIP diff <a href="https://reviews.llvm.org/D87730">https://reviews.llvm.org/D87730</a>, I'm already showing the user these gaps and a reason why they failed.</div><div><pre class="gmail-remarkup-code" style="margin-top:0px;margin-bottom:0px;padding:12px;border:0px;background:rgba(71,87,120,0.08);color:rgb(0,0,0);overflow:auto;border-radius:3px;white-space:pre-wrap;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:15px;font-family:Menlo,Consolas,Monaco,monospace">[4] 0x400529 <+28>: cmpl   $0x3, -0x8(%rbp)
[3] error -13. 'no memory mapped at this address'
[2] 0x40052d <+32>: jle    0x400521</pre></div><div><br></div><div>There's nothing more useful to do besides showing this information somehow. It's information lost, so I think it's fine as it is :)</div><div><br></div><div>However, the real interesting point to discuss is how we could implement reverse debugging under these circumstances. What if you do reverse-next and the trace has a gap but a bunch of instructions before that gap, should we abort the reverse-next and tell the user that there's a gap, then the user somehow has to move backwards in another way if that's the intention? Or should we just move backwards skipping the gap and printing an error message that there's a gap? Probably I'd choose the latter over the former, but I imagine some people would prefer the first. I'd prefer to leave this for a future discussion. Dropping some bit of information here, several IDEs like VSCode already support reverse-debugging controls, so it would make sense to make the default behavior of the LLDB implementation follow those controls, and create some other commands for the folks who want something different.</div><div><br></div><div>> I'm not trying to hold up work: I think these 'dump' subcommands can be hidden, or maybe they could print a 'for lldb developers only' warning until we have a better idea of how users will want to explore a trace.</div><div><br></div><div>I envision these dump commands as the most inefficient way to explore a trace, and I wouldn't add much more to them. I think that the best way to explore is with reverse debugging (e.g. place a breakpoint, do reverse-continue, stop at that breakpoint, move forward and backwards, print the stack trace, move to another breakpoint, etc.) A trace has so much information but the user already has an idea of where they want to look at when root causing a bug, so breakpoints are the easiest interface for the user to tell LLDB what they are interested in. </div><div><br></div><div>> One potential UI metaphor is a slider: the user can see where (which instruction index) in the decoded trace instruction stream they are, and they can move the slider (jump backwards/forwards in the instruction stream) as desired. Wherever they are stopped, they can get an accurate backtrace, look at the call (or line, or instruction-level) execution history, peek ahead at future calls, etc. (Reverse) stepping/continuing could be scene as moving the slider more or less quickly. Maybe it'd be useful to mark a spot to get back to it later.</div><div><br></div><div>We are agreeing on this. I think that reverse debugging controls in the UI are a very good start for that.</div><div><br></div><div>> I'm sure there are other ways to look at a trace. E.g. you could have a view that shows how often each function/line is executed, or you could have an annotated CFG view.</div></div></div><div><br></div><div>Yes! This becomes highly important, especially if there's timing information associated. You could make visualizations over time, with callstacks, statistics, etc. My intention is to eventually flesh out those cool features.</div><div><br></div><div><br></div><div>Thanks,</div><div>- Walter Erquinigo</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 18 set 2020 alle ore 15:32 Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Walter & Greg,<div><br></div><div>Thanks for sharing this RFC, and for your work in this area.<br><div><br><blockquote type="cite"><div>On Sep 17, 2020, at 5:28 PM, Walter via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Hi all,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Here I propose, along with Greg Clayton, Processor Trace support for LLDB. I’m attaching a link to the document that contains this proposal if that’s easier to read for you: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1cOVTGp1sL-5FHBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI_edit-23heading-3Dh.t5mblb9ugv8f&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY&m=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k&s=o6vqoYYbn-Tz_d34hoLJvWhEnnhracOO6yDsMzq8wR0&e=" style="color:rgb(5,99,193)" target="_blank">https://docs.google.com/document/d/1cOVTGp1sL_HBXjP9eB7qjVtDNr5xnuZvUUtv43G5eVI/edit#heading=h.t5mblb9ugv8f</a>. Please make any comments in this mail list.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">If you want to quickly know what Processor Trace can do, you can read this <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__easyperf.net_blog_2019_08_23_Intel-2DProcessor-2DTrace&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=erxV6KMIZvIQjyWYW8YpOiKz-WqJt4giKQA34YMHsRY&m=DuuwXHUQJpW4TcCay4hPsBund-eBI2uVaVimqEPsp5k&s=iaErHaf8byXlZb1YFUk0BpQ-duMhNouUUMyktLm3soQ&e=" style="color:rgb(5,99,193)" target="_blank">https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace</a>.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Any comments are appreciated, especially the ones regarding the commands the user will interact with. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Thanks,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Walter Erquinigo.</pre><div style="font-family:-webkit-standard;border-style:none none solid;border-bottom-width:1pt;border-bottom-color:windowtext;padding:0in 0in 1pt"><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New";border:none;padding:0in"> </pre></div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># RFC: Processor Trace Support in LLDB</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># What is processor tracing?</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Processor tracing works by capturing information about the execution of a process so that the control flow of the program can be reconstructed later. Implementations of this are Intel Processor Trace for X86, x86_64 ([<a href="https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html%5D(https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)" style="color:rgb(5,99,193)" target="_blank">https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)</a>) and ARM CoreSight for some ARM devices ([<a href="https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace%5D(https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)" style="color:rgb(5,99,193)" target="_blank">https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace](https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace)</a>). </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">As a clarifying example, with these technologies it’s possible to trace all the threads of a process, and after the process has finished, reconstruct every single instruction address each thread has executed. This could include some additional information like timestamps, async CPU events, kernel instructions, bus clock ratio changes, etc. On the other hand, memory and registers are not traced as a way to limit the size of the trace.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Intel Processor Trace as the first implementation</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">We’ll focus on Intel Processor Trace (Intel PT), but in a generic way so that in the future similar technologies can be onboarded in LLDB.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Intel PT has the following features:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Control flow tracing in a highly encoded format</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   3% to 5% slowdown when capturing</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   No memory nor registers captured</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Kernel tracing support</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Timestamps of branches are produced, which can be used for profiling</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Adjustable size of trace buffer</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Supported on most Intel CPUs since 2015</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   X86 and x86_64 only</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Official support only on Linux</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Basic support on Windows</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Decoding/analysis can be done on any operating system    </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">A very nice introduction to Intel PT can be found [<a href="https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html%5D(https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)" style="color:rgb(5,99,193)" target="_blank">https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html](https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html)</a> and [<a href="https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace%5D(https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace)" style="color:rgb(5,99,193)" target="_blank">https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace](https://easyperf.net/blog/2019/08/23/Intel-Processor-Trace)</a>. Totally recommended to fully grasp the impact of this project. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">More technical details are in [<a href="https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt%5D(https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt)" style="color:rgb(5,99,193)" target="_blank">https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt](https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/perf-intel-pt.txt)</a>. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Even more technical details are in the processor manual [<a href="https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf%5D(https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf)" style="color:rgb(5,99,193)" target="_blank">https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf](https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf)</a> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Basic Definitions</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Trace file: A trace file basically contains the information of the target addresses of each branch or jump within the program execution in a highly encoded format.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Capturing: The act of tracing a process and producing a trace file.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Decoding: Decoding outputs a sequential list of instructions given a trace file and the images of a process. Decoding is generally an offline step as it’s expensive.</pre></div></div></div></div></div></blockquote><div><br></div><div>Is it possible to decode a small portion of an Intel PT trace file quickly, say, in a few milliseconds? This would be useful if tracing were done in ringbuffer mode, or if the event the user is interested in debugging (along with its relevant execution history) is known to occur at the end of the trace. The user could potentially choose which subset of the trace to decode, and re-decode a different subset if more context is needed.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Trace buffer: In order to limit the size of the trace, an on-memory circular buffer can be used, keeping the most recent branching information. The trace file is a snapshot of this.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Gap: Sporadically some branching information can be lost or be impossible to decode, which creates a gap in the reconstructed control flow.</pre></div></div></div></div></div></blockquote><div><br></div>What mechanisms are available for discerning the root cause of a gap? Does the Intel PT decoder have internal consistency checks that can diagnose hardware bugs (or decoder bugs, for that matter)?</div><div><br></div><div>Also, when a gap occurs, perhaps it's possible that the instructions leading up to the gap are not accurate. E.g., if the decoding process desyncs from the trace file while disassembling, it's possible to accidentally follow (or ignore) a branch. Are there measures to detect/erase those inaccurate instructions prior to a gap?</div><div><br></div><div>Also, how should a gap be represented in the debugger output? E.g., if a gap is encountered while dumping instructions, should the debugger print <gap: instruction unknown>?</div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># New LLDB features</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Loading traces: We want to load traces potentially from other computers, and have LLDB symbolicating it. A flow like the following should be possible \</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace load /path/to/trace</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace dump --instructions</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    pid: '1234', tid: '1981309'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`main</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [57] 0x400549 <+13>: movl   %eax, -0x4(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`bar()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [56] 0x40053b <+46>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [55] 0x40053a <+45>: leave</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [54] 0x400537 <+42>: movl   -0x4(%rbp), %eax</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [53] 0x400535 <+40>: jle    0x400525                  ; <+24> at main.cpp:7</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [52] 0x400531 <+36>: cmpl   $0x3, -0x8(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [51] 0x40052d <+32>: addl   $0x1, -0x8(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [50] 0x40052a <+29>: addl   %eax, -0x4(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`foo()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [49] 0x400567 <+15>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [48] 0x400566 <+14>: popq   %rbp</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [47] 0x400563 <+11>: movl   -0x4(%rbp), %eax</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [46] 0x40055c <+4>: movl   $0x2a, -0x4(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">              ...</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">          [1] 0x400559 <+1>: movq   %rsp, %rbp</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">          [0] 0x400558 <+0>: pushq  %rbp</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">          // Format:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    `  // [instruction index] &lt;instruction disassembly> \</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">`Notice the resemblance to loading a core file, but in this case we can get the control flow, printed in reverse order in this example.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Decoding: LLDB can use libipt ([<a href="https://github.com/intel/libipt%5D(https://github.com/intel/libipt)" style="color:rgb(5,99,193)" target="_blank">https://github.com/intel/libipt](https://github.com/intel/libipt)</a>), which is the low level Intel PT decoding library, to convert trace files into instructions.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Showing instructions: LLDB can output the list of instructions of the control flow, as shown above</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Showing function calls: Similarly, LLDB can print a hierarchical view of the function calls. A flow like this should be possible: \</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace load /path/to/trace</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace dump --function-calls</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    pid: '1234', tid: '1981309'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [50]     a.out`bar()         0x40052a</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [45]       a.out`zaz()       0x400558  </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [40]     a.out`baz()         0x400559  </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [30]   a.out`foo()           0x400567</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    `  [0]  a.out`main              0x400000 \</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> \</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">`This functionality allows LLDB to reconstruct the call stack at any point and potentially  do reverse debugging.</pre></div></div></div></div></blockquote><div><br></div><div>Imho it's important to nail down a user interface metaphor for navigating/exploring a trace before adding any 'dump'-like commands. I don't think we've done that yet.</div><div><br></div><div>I'm not trying to hold up work: I think these 'dump' subcommands can be hidden, or maybe they could print a 'for lldb developers only' warning until we have a better idea of how users will want to explore a trace.</div><div><br></div><div>One potential UI metaphor is a slider: the user can see where (which instruction index) in the decoded trace instruction stream they are, and they can move the slider (jump backwards/forwards in the instruction stream) as desired. Wherever they are stopped, they can get an accurate backtrace, look at the call (or line, or instruction-level) execution history, peek ahead at future calls, etc. (Reverse) stepping/continuing could be scene as moving the slider more or less quickly. Maybe it'd be useful to mark a spot to get back to it later.</div><div><br></div><div>I'm sure there are other ways to look at a trace. E.g. you could have a view that shows how often each function/line is executed, or you could have an annotated CFG view.</div><div><br></div><div>(Stepping back a bit -- I realize these comments are somewhat forward-looking / potentially out of scope for your initial patches. Still, I feel it's worth thinking about early on.)</div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Capturing: LLDB can also do the Intel PT capturing of a live process, so that at any stop the user can do reverse stepping or simply inspect the trace. A possible flow is:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ <stopped at main></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ b main.cpp:50</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace start intel-pt // this initiates the tracing</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ continue</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ <stopped at main.cpp:50></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace dump --instructions</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">pid: '1234', tid: '1981309'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`main</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [57] 0x400549 <+13>: movl   %eax, -0x4(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`bar()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [56] 0x40053b <+46>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [55] 0x40053a <+45>: leave</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    Displaying time information: If the trace contains timing information, we could also display it along with each instruction, e.g.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    a.out`bar()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    [56: 1600284226]: 0x40053b <+46>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ...</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    [4:  1600284200]: 0x40053a <+45>: leave</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    // Format:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    // [instruction index: unix timestamp] <instruction disassembly></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    ```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    Furthermore, we could display the time spent in each function.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Future LLDB features</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Reverse Stepping: With the hierarchical reconstruction of the function calls, along with the individual instructions, LLDB can offer reverse stepping. Operations like reverse-next, reverse-step-out, reverse-continue could work by traversing the trace. We plan to work on this once the features presented above are in place.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Trace-based profiling</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   SB API of the mentioned features</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Why is this useful?</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Bug root-causing:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    *   For example, a crash in a production Release build ends up being analyzed with logs, a coredump, and a stack trace. Logs are not comprehensive, and a stack trace only contains the final state of the program. Providing the user with the control flow of the last milliseconds gives a tremendous amount of information that is game-changing in root-causing issues. It could be said that the user goes from a single stack trace to a list of stack traces.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    *   Reverse stepping enables more efficient debugging, as it reduces the number of iterations to efficiently root-cause bugs. More often than not, reproducing a bug takes a considerable amount of time, and the user needs to reproduce it several times until the correct breakpoints are hit. This takes a considerable amount of time. Giving the user the information of what has been executed so far can help them figuring out where’s the location to place a breakpoint, or to very easily figure out what went wrong.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Low cost: unlike other similar technologies, Intel PT has an almost negligible performance cost regardless of whether the build is optimized or not, making it appealing to a wide range of scenarios.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   This infrastructure can be used for enabling other tools like non-sample-based profilers with instruction-level accuracy, security analyzers that check if certain memory regions are executed, and trace comparators, which could find bugs by comparing similar traces.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Goals of this document:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Gather feedback on the basic Trace implementation, which would include the following basic operations: loading, decoding, and dumping.</pre></div></div></div></div></blockquote><div><br></div><div>All this sounds good to me with the caveat that, as mentioned above, we probably should indicate to users that the `trace dump` facility is not stable / likely to change.</div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Create awareness about this work.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Get a green light on the current set of patches implementing this feature starting with <a href="https://reviews.llvm.org/D85705" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D85705</a>.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Non-Goals:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Discuss how reverse-stepping will be implemented. This can be left for another discussion. Once the Trace architecture is in place and robust, reverse-stepping can then be discussed, as it’s a more controversial change than this one.</pre></div></div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Explain thoroughly Intel PT. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Existing Tool Support</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   GDB has a basic implementation of the features above ([<a href="https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html%5D(https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html)" style="color:rgb(5,99,193)" target="_blank">https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html](https://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html)</a>) and some ideas are taken from there.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Perf is a standalone tool that can do capturing and decoding.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   The Linux kernel has full support for doing capturing at thread, logical cpu or cgroup level. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">*   Intel developed a basic version of Intel PT support in LLDB as an external plugin. [<a href="https://reviews.llvm.org/D33674%5D(https://reviews.llvm.org/D33674)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D33674](https://reviews.llvm.org/D33674)</a>, [<a href="https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b%5D(https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b](https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)</a>. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># New Trace Commands</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Based on this patch [<a href="https://reviews.llvm.org/D85705%5D(https://reviews.llvm.org/D85705)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D85705](https://reviews.llvm.org/D85705)</a>, there would be a common Trace class along with plug-in implementations.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">## Trace loading</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace load /path/to/trace/settings/file.json</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">As decoding a trace requires the images of the object files, the trace files and some CPU information, it’s convenient to have a JSON file that describes an entire trace session. The following JSON schema could be used.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">{</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">"trace": {       </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   … // plug-in specific information </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> },</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> "processes": [      // process information common to all trace plug-ins</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "pid": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "triple": string, // llvm-triple</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "threads": [</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "tid": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "traceFile": string</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     ],</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "modules": [</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "systemPath": string, // original path of the module at runtime</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "file"?: string, // copy of the file if not available at "systemPath"</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "loadAddress": string, // string address in hex or decimal form</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "uuid"?: string,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     ]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> ]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">}</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">// Notes:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">// All paths are either absolute or relative to the settings file.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">**Corefiles:**</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">We plan to extend this schema to support corefiles, but we would leave it out of this discussion, as can be easily seen as an extension of this basic schema.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">**Implementation details:**</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">To make our first implementation easier, we’ll ask for an individual trace file per thread. This is the simpler collection mode for Intel PT. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">The entire json file will be translated into a Trace object, which contains the trace information of each thread and process in it. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Each process in the json file will be represented as a new Target. Similarly, threads and modules for each target will be created following the json file. This is very similar to what loading a minidump or coredump does.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Each Target will be associated with a Trace, and multiple targets can share the same Trace. The contract is that Trace is assumed to end at the current PC of each thread of the target.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace schema &lt;plug-in></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">This command prints the JSON schema of the trace settings file for the provided plug-in. It would output something similar to this</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">{</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">"trace": {       </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   "type": "intel-pt",</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   "pt_cpu": {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "vendor": "intel" | "unknown",</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "family": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "model": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "stepping": integer</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> },</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> "processes": [      </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "pid": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "triple": string, // llvm-triple</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "threads": [</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "tid": integer,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "traceFile": string</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     ],</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     "modules": [</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       {</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "systemPath": string, // original path of the module at runtime</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "file"?: string, // copy of the file if not available at "systemPath"</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "loadAddress": string, // string address in hex or decimal form</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">         "uuid"?: string,</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">       }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">     ]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">   }</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> ]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">}</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">// Notes:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">// All paths are either absolute or relative to the settings file.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace dump [--verbose] [-t tid1] [-t tid2] ...</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Print the trace information corresponding to the provided thread ids of the currently selected target, which would mainly include the same information as the trace settings file. If no tid is provided, the currently selected thread is used. This would be useful for debugging. The information would be like</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">  Modules: </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    &lt;module info like systemPath, file, load address, uuid, size></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">  Threads:</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    &lt;thread info like location of trace file, number of instructions (if already decoded), number   of function calls (if already decoded)></pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">If &lt;--verbose> is passed, the original settings.json file is printed as well.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">## Decoder-based commands</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">The following commands require decoding the trace and are of the form. “trace dump &lt;action> [-t &lt;tid>]”. If tids are not specified, then the current thread or the current target will be used.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace dump --instructions [-t &lt;tid>] [-c &lt;count> = 10] [-o &lt;offset> = 0]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">This command would print the last &lt;count> instructions starting at the given offset from the last instruction in the trace. The output would be similar to that of the “disassembly” command and would include timing information if available.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace dump --instructions -c 5</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    pid: '1234', tid: '1981309'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`main</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [57] 0x400549 <+13>: movl   %eax, -0x4(%rbp)</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`bar()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [56] 0x40053b <+46>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [55] 0x40053a <+45>: leave</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [54] error -13. 'no memory mapped at this address'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      a.out`foo()</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [53] 0x400567 <+15>: retq</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Repeating the command would continue printing where it was left off in the last run.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">**Implementation details:**</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Each instruction output by the decoder is either an actual instruction or an error. An error can be caused due to a collection error (e.g. internal CPU buffer overflow error) or a decoding error (e.g. the image of an object file is missing while decoding). These errors represent gaps in the trace and the user should know about them, so we print them accordingly in this dump.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Each instruction (including errors) has an index in the decoded trace, and serves as a checkpoint.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace dump --function-calls [-t &lt;tid>] [-c &lt;count> = 10] [-o &lt;offset> = 0] [--flat]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">This command would print the hierarchical list of function calls. Similar to the “--instructions” command, it would show the last &lt;count> function calls with the given offset from the last instructions. Timing information would be included if available.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    $ trace dump --function-calls</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">    pid: '1234', tid: '1981309'</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [50]     a.out`bar()         0x40052a</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [45]       a.out`zaz()       0x400558  </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [40]     a.out`baz()         0x400559  </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [30]   a.out`foo()           0x400567</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">      [0]  a.out`main              0x400000</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">```</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Repeating the command would continue printing where it was left off in the last run.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">If &lt;--flat> is passed, then instead of a hierarchical view, a flat list would be produced.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">## Capturing command</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace start &lt;plugin_name> [-t &lt;tid>] [--all] [-b &lt;buffer_size_in_KB>]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">This command will start tracing the given thread of the currently selected target, or all the threads of that target if “--all” is passed. If “--all” is passed, any thread created after this command will also be traced automatically.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Besides, the optional -b parameter can define the size of each trace buffer to be created. I haven’t yet decided a default one, but 1M might be acceptable, as it traces around 1 million instructions on average according to Intel, and that’s more than enough for a useful analysis.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">For an initial implementation, the plugin_name parameter will be required (e.g. intel-pt). Later a more automated mechanism for finding the right plugin can be implemented.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">**Implementation notes:**</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">There’s already a basic implementation in lldb as an external plugin. It’s in [<a href="https://reviews.llvm.org/source/llvm-github/browse/master/lldb/tools/intel-features/intel-pt/%5D(https://reviews.llvm.org/source/llvm-github/browse/master/lldb/tools/intel-features/intel-pt/)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/source/llvm-github/browse/master/lldb/tools/intel-features/intel-pt/](https://reviews.llvm.org/source/llvm-github/browse/master/lldb/tools/intel-features/intel-pt/)</a> created by [<a href="https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b%5D(https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b](https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)</a>. It hasn’t received much attention and has been mostly unmaintained since it was created. It’s already capable of tracing a given thread and collecting the trace buffer. We plan to reuse that logic, which is already working.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">A Trace object will be created and will be associated with the current Target.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Any interaction with trace, like dumping instructions, will trigger a fetch of the most recent trace buffer, unless it hasn’t changed. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">When multiple threads are traced, each one will have its own trace buffer, as sharing one buffer in multiple threads requires knowing when each context switch happened so that the decoded trace can be split correctly among threads. This is beyond the scope of the initial version of this project.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">### $ trace save /path/to/file.json [--copy-images]</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">This creates a bundle trace with settings saved in the given json file for the current process. By default, it doesn’t create any copy of the images loaded on the process, unless the “--copy-images” parameter is specified. That parameter is useful for analyzing the trace in a machine other than where it was captured. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Remote Protocol Changes</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">No remote protocol changes are required, as [<a href="https://reviews.llvm.org/D33674%5D(https://reviews.llvm.org/D33674)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D33674](https://reviews.llvm.org/D33674)</a> and [<a href="https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b%5D(https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b](https://reviews.llvm.org/rG307db0f8974d1b28d7b237cb0d50895efc7f6e6b)</a> already created them some years ago.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Build Requirements</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">In order to build LLDB with this support, it has to be linked with a build of libipt [<a href="https://github.com/intel/libipt%5D(https://github.com/intel/libipt)" style="color:rgb(5,99,193)" target="_blank">https://github.com/intel/libipt](https://github.com/intel/libipt)</a>, which is the decoder.</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Operating System Requirements for Collection/Tracing</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Collection can only be done on linux if the file /sys/bus/event_source/devices/intel_pt/type is defined. The logic gating this feature is already checked in and defined in [<a href="https://reviews.llvm.org/D33674%5D(https://reviews.llvm.org/D33674)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D33674](https://reviews.llvm.org/D33674)</a>. </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""># Testing</pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""> </pre><pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">It’s fortunately straightforward to test this feature. It’s possible to capture traces with perf or with the future “trace start” / ”trace save” commands and create trace bundles with their corresponding settings .json file. Analyzing those traces should give the same results on any machine, making testing deterministic. [<a href="https://reviews.llvm.org/D85705%5D(https://reviews.llvm.org/D85705)" style="color:rgb(5,99,193)" target="_blank">https://reviews.llvm.org/D85705](https://reviews.llvm.org/D85705)</a> and descendents already implement some deterministic tests.</pre></div></div></div></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></blockquote></div><br></div><div>vedant</div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>- Walter Erquínigo Pezo<br><br></div></div></div>