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
Hi Greg
Please find any answers/queries inlined:
On Thu, Feb 4, 2016 at 9:58 PM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
>> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>>
>> On 4 February 2016 at 10:04, Ravitheja Addepally
>> wrot
> On Feb 4, 2016, at 2:24 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 4 February 2016 at 10:04, Ravitheja Addepally
> wrote:
>> Hello Pavel,
>>In the case of expression evaluation approach you mentioned
>> that:
>> 1. The data could be accessible only when the target is stopp
On 4 February 2016 at 12:49, Abhishek Aggarwal wrote:
> Hello Pavel
>
> As per my understanding, instead of doing it by expression evaluation
> if the code (to enable pt and gathering the raw traces) is written on
> lldb-server side, then also lldb-server will have to wait for the
> inferior to st
Hello Pavel
As per my understanding, instead of doing it by expression evaluation
if the code (to enable pt and gathering the raw traces) is written on
lldb-server side, then also lldb-server will have to wait for the
inferior to stop in order to encapsulate all the traces in packets and
send them
Yes, thanx for the clarification.
On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath wrote:
> On 4 February 2016 at 10:04, Ravitheja Addepally
> wrote:
> > Hello Pavel,
> > In the case of expression evaluation approach you
> mentioned
> > that:
> > 1. The data could be accessible onl
On 4 February 2016 at 10:04, Ravitheja Addepally
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 ru
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 ?
2. What sort of noise were you referring to ?
BR,
A Ravi Theja
On Mon, Feb 1, 2016 at 1:05 PM, Tamas Berghammer
wrote:
If you want to go with the path to implement it outside LLDB then I would
suggest to implement it with an out of tree plugin written in C++. You can
use the SB API the same way as you can from python and additionally it have
a few advantages:
* You have a C/C++ API what makes it easy to integrate t
Speaking for Android Studio, I think that we *could* use a
python-based implementation (hard to say exactly without knowing the
details of the implementation), but I believe a different
implementation could be *easier* to integrate. Plus, if the solution
integrates more closely with lldb, we could
And what about the ease of integration into a an IDE, I don't really know
if the python based approach would be usable or not in this context ?
On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath wrote:
> It feels to me that the python based approach could run into a dead
> end fairly quickly: a) you
It feels to me that the python based approach could run into a dead
end fairly quickly: a) you can only access the data when the target is
stopped; b) the self-tracing means that the evaluation of these
expressions would introduce noise in the data; c) overhead of all the
extra packets(?).
So, I w
Ok, that is one option, but one of the aim for this activity is to make the
data available for use by the IDE's like Android Studio or XCode or any
other that may want to display this information in its environment so
keeping that in consideration would the complete python based approach be
useful
One thing to think about is you can actually just run an expression in the
program that is being debugged without needing to change anything in the GDB
remote server. So this can all be done via python commands and would require no
changes to anything. So you can run an expression to enable the
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 wi
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, 20
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
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
th
[ 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 inv
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
Ptrace
20 matches
Mail list logo
