<div dir="ltr">There are two different kinds of performance counters: OS performance counters and CPU performance counters. It sounds like you're talking about the latter, but it's worth considering whether this could be designed in a way to support both (i.e. even if you don't do both yourself, at least make the machinery reusable and apply to both for when someone else wanted to come through and add OS perf counters).<div><br></div><div>There is also the question of this third party library. Do we take a hard dependency on libipt (probably a non-starter), or only use it if it's available (much better)?</div><div><br></div><div>As Pavel said, how are you planning to present the information to the user? Through some sort of top level command like "perfcount instructions_retired"?</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[ Moving this discussion back to the list. I pressed the wrong button<br>
when replying.]<br>
<br>
Thanks for the explanation Ravi. It sounds like a very useful feature<br>
indeed. I've found a reference to the debugserver profile data in<br>
GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with<br>
your investigation. Maybe also someone more knowledgeable can explain<br>
what those A packets are used for (?).<br>
<br>
<br>
On 21 October 2015 at 15:48, Ravitheja Addepally<br>
<<a href="mailto:ravithejawork@gmail.com" target="_blank">ravithejawork@gmail.com</a>> wrote:<br>
> Hi,<br>
> Thanx for your reply, some of the future processors to be released by<br>
> Intel have this hardware support for recording the instructions that were<br>
> executed by the processor and this recording process is also quite fast and<br>
> does not add too much computational load. Now this hardware is made<br>
> accessible via the perf_event_interface where one could map a region of<br>
> memory for this purpose by passing it as an argument to this<br>
> perf_event_interface. The recorded instructions are then written to the<br>
> memory region assigned. Now this is basically the raw information, which can<br>
> be obtained from the hardware. It can be interpreted and presented to the<br>
> user in the following ways -><br>
><br>
> 1) Instruction history - where the user gets basically a list of all<br>
> instructions that were executed<br>
> 2) Function Call History - It is also possible to get a list of all the<br>
> functions called in the inferior<br>
> 3) Reverse Debugging with limited information - In GDB this is only the<br>
> functions executed.<br>
><br>
> This raw information also needs to decoded (even before you can disassemble<br>
> it ), there is already a library released by Intel called libipt which can<br>
> do that. At the moment we plan to work with Instruction History.<br>
> I will look into the debugserver infrastructure and get back to you. I guess<br>
> for the server client communication we would rely on packets only. In case<br>
> of concerns about too much data being transferred, we can limit the number<br>
> of entries we report because anyway the amount of data recorded is too big<br>
> to present all at once so we would have to resort to something like a<br>
> viewport.<br>
><br>
> Since a lot of instructions can be recorded this way, the function call<br>
> history can be quite useful for debugging and especially since it is a lot<br>
> faster to collect function traces this way.<br>
><br>
> -ravi<br>
><br>
> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I am not really familiar with the perf_event interface (and I suspect<br>
>> others aren't also), so it might help if you explain what kind of<br>
>> information do you plan to collect from there.<br>
>><br>
>> As for the PtraceWrapper question, I think that really depends on<br>
>> bigger design decisions. My two main questions for a feature like this<br>
>> would be:<br>
>> - How are you going to present this information to the user? (I know<br>
>> debugserver can report some performance data... Have you looked into<br>
>> how that works? Do you plan to reuse some parts of that<br>
>> infrastructure?)<br>
>> - How will you get the information from the server to the client?<br>
>><br>
>> pl<br>
>><br>
>><br>
>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev<br>
>> <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
>> > Hello,<br>
>> > I want to implement support for reading Performance measurement<br>
>> > information using the perf_event_open system calls. The motive is to add<br>
>> > support for Intel PT hardware feature, which is available through the<br>
>> > perf_event interface. I was thinking of implementing a new Wrapper like<br>
>> > PtraceWrapper in NativeProcessLinux files. My query is that, is this a<br>
>> > correct place to start or not ? in case not, could someone suggest me<br>
>> > another place to begin with ?<br>
>> ><br>
>> > BR,<br>
>> > A Ravi Theja<br>
>> ><br>
>> ><br>
>> > _______________________________________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
>> ><br>
><br>
><br>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div>