[lldb-dev] Inquiry for performance monitors

[Abhishek Aggarwal via lldb-dev]

Hi Everyone

I have developed a tool that facilitates lldb users using Intel(R)
Processor Trace technology for debugging applications (as per discussions
in this thread). The patch is https://reviews.llvm.org/D33035.

Some highlights of this tool are:
1. The tool is built on top of lldb. It is not a part of liblldb shared
library. It resides in tool/intel-features folder. Anyone willing to use
this feature can compile this tool (by enabling some extra flags) using
cmake while building lldb.
2. As it was suggested, the trace decoding library hasn't been made a part
of lldb repository. It can be downloaded from the corresponding github repo.
3. All intel specific features are combined to form single shared library
thereby not cluttering lldb repository with each intel specific feature
(proposed by Pavel).

If something has changed or you have new concerns regarding this tool since
the last discussion in this thread, please let me know.

- Abhishek


On Fri, Feb 5, 2016 at 4:38 PM, Abhishek Aggarwal <abhiinnitald at gmail.com>
wrote:

> Hi Greg
>
> Please find any answers/queries inlined:
>
> On Thu, Feb 4, 2016 at 9:58 PM, Greg Clayton via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> >> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >> On 4 February 2016 at 10:04, Ravitheja Addepally
> >> <ravithejawork at gmail.com> wrote:
> >>> Hello Pavel,
> >>>                In the case of expression evaluation approach you
> mentioned
> >>> that:
> >>> 1. The data could be accessible only when the target is stopped. why
> is that
> >>> ?
> >> If I understand the approach correctly, the idea is the run all perf
> >> calls as expressions in the debugger. Something like
> >> lldb> expr perf_event_open(...)
> >> We need to stop the target to be able to do something like that, as we
> >> need to fiddle with its registers. I don't see any way around that...
> >>
> >>> 2. What sort of noise were you referring to ?
> >> Since now all the perf calls will be expressions executed within the
> >> context of the process being traced, they themselves will show up in
> >> the trace. I am sure we could filter that out somehow, but it feels
> >> like an added complication..
> >>
> >> Does that make it any clearer?
> >
> > So a few questions: people seem worried about running something in the
> process if expression are being used. Are you saying that if the process is
> on the local machine, process 1 can just open up a file descriptor to the
> trace data for process 2? If so, why pass this through lldb-server?
>
> As you have also mentioned later in your email, irrespective of what
> approach we use to implement this feature, we will have to send the trace
> data from lldb-server to client in case of remote debugging. Moreover even
> for local debugging, the current architecture of lldb is a client-server
> architecture (atleast for macosx, linux and freebsd) as per my knowledge.
> Hence, traces will have to be sent in form of packets from server to
> client even for the expression evaluation approach.
>
> > I am not a big fan making the lldb-server become the conduits for a ton
> of information. It just isn't built for that high volumes of data coming
> in. I can be done, but that doesn't mean it should.  If everyone starts
> passing data like memory usage, CPU time, trace info, backtraces and more
> through asynchronously through lldb-server, it will become a very crowded
> communication channel.
> >
> As per my understanding, one of the difference the expression evaluation
> approach provides is to disallow sending traces from server to client
> asynchronously (as traces can't be sent until inferior stops). If increased
> number of asynchronous packets are the concern here then we can choose to
> send the trace data only synchronously (i.e. only after the inferior
> stops). Or can't we ?
>
> > You don't need python if you want to do this using the lldb API. If your
> IDE is already linking against the LLDB shared library, it can just run the
> expressions using the public LLDB API. This is how view debugging is
> implemented in Xcode. It runs complex expressions that gather all data
> about a view and its subviews and returns all the layers in a blob of data
> that can be serialized by the expression, retrieved by Xcode (memory read
> from the process), and then de-serialized by the IDE into a format that can
> be used. If your IDE can access the trace data for another process, why not
> just read it from the IDE itself? Why get the lldb-server involved? Granted
> the remote debugging parts of this make an argument for including it in the
> lldb-server. But if you go this route you need to make a base
> implementation for trace data that will work for any trace data, have trace
> data plug-ins that somehow know how to interpret the data and provide.
> >
> Thanks for suggesting this.
>
> > How do you say "here is a blob of trace data" I just got from some
> process, go find me a plug-in that can parse it. You might have to say
> "here is a blob of data" and it is for the "intel" trace data plug-in. How
> are we going to know which trace data to ask for? Is the packet we send to
> lldb-server going to reply to "qGetTraceData" with something that says the
> type of data is "intel-IEEE-version-123.3.1" and the data is "xxxxxxx"?
> Then we would find a plug-in in LLDB for that trace data that can parse it?
> So you will need to think about completely abstracting the whole notion of
> trace data into some sensible API that gets exposed via SBProcess.
> >
> We need to think a bit more on this.
>
> > So yes, there are two approaches to take. Let me know which one is the
> way you want to go. But I really want to avoid the GDB remote protocol's
> async packets becoming the conduit for a boat load of information.
> >
> In order to configure/start/finish the tracing feature, a lot of
> expression evaluations will have to be done (atleast perf_event_open(),
> mmap(), perf_event_close() are the ones I know of). The main reason I am
> skeptical of expression evaluation approach is the amount of extra packets
> to be sent to the lldb-server to configure/start/finish tracing. Hence, I
> am more in favor of writing the code to configure/start/finish the
> tracing on lldb-server side. Once we have all the traces with us and
> inferior stops, we can send them only synchronously over the communication
> channel.
>
> Please correct me if I there is something wrong with my understanding.
> Thanks a lot for your detailed email.
>
> > Greg Clayton
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> - Abhishek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170619/eac1a5fd/attachment.html>