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'.
# return False # continue
return True # stop
is that the return value from the breakpoint command only matters if you
haven't already started the process running again, which you have with the
"thread step-scripted" command. But if you pass resume_immediately -> False to
StepUsingScriptedStep, then that will just queue the thread plan but not start
the process going again. Then the restart will be in a more orderly place in
lldb.
All the commands that can resume the process really need to have a "do it now"
and a "request to do this" mode. In breakpoint commands and the like, they
should use the latter mode (a) so we can do a better job of arbitrating "I hit
two breakpoints, A wants to continue but B wants to stop" and (b) so we don't
have to deal with the complexities of restarting when we aren't quite done with
handling the last stop. But for now you have to be a little careful in
breakpoint callbacks.
Jim
> On Sep 27, 2019, at 8:33 AM, Nikita Karetnikov <[email protected]> wrote:
>
> 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/75c8a0b814246b322d562e7333eb4ba9
>
> Let me know if you find a way to do this via the Python API.
>
> Thanks,
> Nikita
>
_______________________________________________
lldb-dev mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
