<div dir="ltr">Yes, thanx for the clarification. </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 4, 2016 at 11:24 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4 February 2016 at 10:04, Ravitheja Addepally<br>
<span class=""><<a href="mailto:ravithejawork@gmail.com">ravithejawork@gmail.com</a>> wrote:<br>
> Hello Pavel,<br>
>                 In the case of expression evaluation approach you mentioned<br>
> that:<br>
> 1. The data could be accessible only when the target is stopped. why is that<br>
> ?<br>
</span>If I understand the approach correctly, the idea is the run all perf<br>
calls as expressions in the debugger. Something like<br>
lldb> expr perf_event_open(...)<br>
We need to stop the target to be able to do something like that, as we<br>
need to fiddle with its registers. I don't see any way around that...<br>
<span class=""><br>
> 2. What sort of noise were you referring to ?<br>
</span>Since now all the perf calls will be expressions executed within the<br>
context of the process being traced, they themselves will show up in<br>
the trace. I am sure we could filter that out somehow, but it feels<br>
like an added complication..<br>
<br>
Does that make it any clearer?<br>
<span class="HOEnZb"><font color="#888888"><br>
pl<br>
</font></span></blockquote></div><br></div>