Jim,
> So the problem you are having is getting the scripted step started in
"trace"
> with the SBThread::StepUsingScriptedStep? Did you try passing False for
> "resume_immediately" and then returning False from "trace".
Yes, I did. In fact, I tried all these combinations:
resume_immediately =
So the problem you are having is getting the scripted step started in "trace"
with the SBThread::StepUsingScriptedStep? Did you try passing False for
"resume_immediately" and then returning False from "trace".
The explanation for:
# XXX: Doesn't seem to matter with 'thread step-scripted
Jim,
> Does that simple use of the scripted plan also work for you?
No, that doesn't work for me. My original script does more stuff, so I
need to
pass the state via global variables.
However, I think I've figured out a way to do what I want:
https://gist.github.com/nkaretnikov/75c8a0b814246b32
Nikita,
There was a lot of other stuff in that scripted_step.py beyond the plan class
itself. I didn't follow what that did altogether. But if I removed all that
stuff, and changed your plan slightly to not rely on the global TARGET and
START_ADDRESS (I attached my simplified version below),
Jim,
>> Not sure if my current version of 'SimpleStep' is correct (I've made a
few
>> changes since testing via 'thread step-scripted'), but nothing happens
(no
>> prints on '__init__') when I add the class via
'StepUsingScriptedThreadPlan' in
>> the callback.
>>
>> What's the proper way to do thi
> On Sep 21, 2019, at 11:11 AM, Nikita Karetnikov wrote:
>
> Jim,
>
> > My model for this sort of tracing activity is that you are writing a fancy
> > kind
> > of “step” operation. You would write a fancy step & record plan that would
> > proceed along however you wanted and log at each stop
Jim,
> My model for this sort of tracing activity is that you are writing a
fancy kind
> of “step” operation. You would write a fancy step & record plan that
would
> proceed along however you wanted and log at each stop. Then your
breakpoint
> callback would just queue up this step-and-trace pla
lldb doesn’t currently support breakpoint callbacks that try to control running
the target in the callback. I’m not sure how easy it would be to support that
reliably, but anyway, that doesn’t work at present.
My model for this sort of tracing activity is that you are writing a fancy kind
of “
Hello,
I'm trying to figure out how to write a simple tracer. Specifically, I
want to
perform some 'step's after a breakpoint callback fires. How do I do that in
async mode?
Here's my attempt:
https://gist.github.com/nkaretnikov/6ee00afabf73332c5a89eacb610369c2
The problem is that pc is not up
