[lldb-dev] Inquiry for performance monitors

[Abhishek Aggarwal via lldb-dev]

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/20160205/8128e40f/attachment-0001.html>