[lldb-dev] Inquiry for performance monitors

Thu Jan 21 07:04:47 PST 2016

Hello,
      Regarding the questions in this thread please find the answers ->

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?) and How will you get the information from the server to
the client?

 Currently I plan to show a list of instructions that have been executed so
far, I saw the
implementation suggested by pavel, the already present infrastructure is a
little bit lacking in terms of the needs of the
project, but I plan to follow a similar approach, i.e to extract the raw
trace data by querying the server (which can use the
perf_event_open to get the raw trace data from the kernel) and transport it
through gdb packets ( qXfer packets
https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
At the client side the raw trace data
could be passed on to python based command that could decode the data. This
also eliminates the dependency of libipt since LLDB
would not decode the data itself.

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)?

With the above mentioned way LLDB would not need the library, who ever
wants to use the python command would have to install it separately but
LLDB wont need it

With the performance counters, the interface would still be
perf_event_open, so if there was a perf_wrapper in LLDB server then it
could be reused to configure and use the
software performance counters as well, you would just need to pass
different attributes in the perf_event_open system call, plus I think the
perf_wrapper could be reused to
get CoreSight information as well (see https://lwn.net/Articles/664236/ )

On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton <gclayton at apple.com> wrote:

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160121/518815d8/attachment-0001.html>