[lldb-dev] Inquiry for performance monitors

Wed Oct 21 11:57:53 PDT 2015

one main benefit to doing this externally is allow this to be done remotely over any debugger connection. If you can run expressions to enable/disable/setup the memory buffer/access the buffer contents, then you don't need to add code into the debugger to actually do this.

Greg

> On Oct 21, 2015, at 11:54 AM, Greg Clayton <gclayton at apple.com> wrote:
> 
> IMHO the best way to provide this information is to implement reverse debugging packets in a GDB server (lldb-server). If you enable this feature via some packet to lldb-server, and that enables the gathering of data that keeps the last N instructions run by all threads in some buffer that gets overwritten. The lldb-server enables it and gives a buffer to the perf_event_interface(). Then clients can ask the lldb-server to step back in any thread. Only when the data is requested do we actually use the data to implement the reverse stepping.
> 
> Another way to do this would be to use a python based command that can be added to any target that supports this. The plug-in could install a set of LLDB commands. To see how to create new lldb command line commands in python, see the section named "CREATE A NEW LLDB COMMAND USING A PYTHON FUNCTION" on the http://lldb.llvm.org/python-reference.html web page.
> 
> Then you can have some commands like:
> 
> intel-pt-start
> intel-pt-dump
> intel-pt-stop
> 
> Each command could have options and arguments as desired. The "intel-pt-start" command could make an expression call to enable the feature in the target by running and expression that runs the some perf_event_interface calls that would allocate some memory and hand it to the Intel PT stuff. The "intel-pt-dump" could just give a raw dump all of history for one or more threads (again, add options and arguments as needed to this command). The python code could bridge to C and use the intel libraries that know how to process the data.
> 
> If this all goes well we can think about building it into LLDB as a built in command.
> 
> 
>> On Oct 21, 2015, at 9:50 AM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>> 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).
>> 
>> 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)?
>> 
>> 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"?
>> 
>> On Wed, Oct 21, 2015 at 8:16 AM Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> [ Moving this discussion back to the list. I pressed the wrong button
>> when replying.]
>> 
>> Thanks for the explanation Ravi. It sounds like a very useful feature
>> indeed. I've found a reference to the debugserver profile data in
>> GDBRemoteCommunicationClient.cpp:1276, so maybe that will help with
>> your investigation. Maybe also someone more knowledgeable can explain
>> what those A packets are used for (?).
>> 
>> 
>> On 21 October 2015 at 15:48, Ravitheja Addepally
>> <ravithejawork at gmail.com> wrote:
>>> Hi,
>>>   Thanx for your reply, some of the future processors to be released by
>>> Intel have this hardware support for recording the instructions that were
>>> executed by the processor and this recording process is also quite fast and
>>> does not add too much computational load. Now this hardware is made
>>> accessible via the perf_event_interface where one could map a region of
>>> memory for this purpose by passing it as an argument to this
>>> perf_event_interface. The recorded instructions are then written to the
>>> memory region assigned. Now this is basically the raw information, which can
>>> be obtained from the hardware. It can be interpreted and presented to the
>>> user in the following ways ->
>>> 
>>> 1) Instruction history - where the user gets basically a list of all
>>> instructions that were executed
>>> 2) Function Call History - It is also possible to get a list of all the
>>> functions called in the inferior
>>> 3) Reverse Debugging with limited information - In GDB this is only the
>>> functions executed.
>>> 
>>> This raw information also needs to decoded (even before you can disassemble
>>> it ), there is already a library released by Intel called libipt which can
>>> do that. At the moment we plan to work with Instruction History.
>>> I will look into the debugserver infrastructure and get back to you. I guess
>>> for the server client communication we would rely on packets only. In case
>>> of concerns about too much data being transferred, we can limit the number
>>> of entries we report because anyway the amount of data recorded is too big
>>> to present all at once so we would have to resort to something like a
>>> viewport.
>>> 
>>> Since a lot of instructions can be recorded this way, the function call
>>> history can be quite useful for debugging and especially since it is a lot
>>> faster to collect function traces this way.
>>> 
>>> -ravi
>>> 
>>> On Wed, Oct 21, 2015 at 3:14 PM, Pavel Labath <labath at google.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I am not really familiar with the perf_event interface (and I suspect
>>>> others aren't also), so it might help if you explain what kind of
>>>> information do you plan to collect from there.
>>>> 
>>>> As for the PtraceWrapper question, I think that really depends on
>>>> bigger design decisions. My two main questions for a feature like this
>>>> would be:
>>>> - How are you going to present this information to the user? (I know
>>>> debugserver can report some performance data... Have you looked into
>>>> how that works? Do you plan to reuse some parts of that
>>>> infrastructure?)
>>>> - How will you get the information from the server to the client?
>>>> 
>>>> pl
>>>> 
>>>> 
>>>> On 21 October 2015 at 13:41, Ravitheja Addepally via lldb-dev
>>>> <lldb-dev at lists.llvm.org> wrote:
>>>>> Hello,
>>>>>       I want to implement support for reading Performance measurement
>>>>> information using the perf_event_open system calls. The motive is to add
>>>>> support for Intel PT hardware feature, which is available through the
>>>>> perf_event interface. I was thinking of implementing a new Wrapper like
>>>>> PtraceWrapper in NativeProcessLinux files. My query is that, is this a
>>>>> correct place to start or not ? in case not, could someone suggest me
>>>>> another place to begin with ?
>>>>> 
>>>>> BR,
>>>>> A Ravi Theja
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>> 
>>> 
>>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 