[lldb-dev] Stepping in a breakpoint callback with Python

[Jim Ingham via lldb-dev]

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 <nikita at karetnikov.org> 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
>