In lldb as it stands now, any action in a breakpoint command callback that 
continues the process you are debugging (step, step-out, fin, etc) will 
terminate the callback.  That restriction is a side effect of the fact that the 
lldb command interpreter is not re-entrant.  It couldn't handle the step 
hitting another breakpoint that also has a command.

The scripted step was a way to provide a more powerful execution control that 
you can arrange with breakpoint callbacks and commands.  It's somewhat limited 
in what it can do - in particular you can't really use lldb commands in the 
methods of the step - though you can get around that by using the SB API's for 
whatever data you want to report.

If you can issue a "step" command in your non-interactive debug session, you 
should be able to use the scripted step plan.  The header of that file shows 
how to import the Python that implements the step, and then how to invoke it.

However, for your purposes, it might be simpler to invert the problem and make 
your driver be directly in control of the stop events and of continuing, rather 
than doing it with breakpoints & breakpoint commands.  That is a more 
straightforward programming model.  Have  a look at the process_events.py 
example in the examples/python directory to see how to do that. That example 
starts with the code to handle arguments, that part is interesting but not 
necessarily relevant.  The relevant bits start around the comment 

                listener = debugger.GetListener()
                # sign up for process state change events
                  ...

Jim


> On Jul 9, 2017, at 10:45 PM, Bibhas Acharya via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
> 
> Hello,
> 
> I'm trying to use the C++ SB API to write a function level tracer. Here's my 
> code (along with the terminal output):
> 
> https://gist.github.com/bibhas/3ae690a2e983b00d96e75d792e92b59c
> 
> My problem is that when inside the breakpoint callback, I can't seem to make 
> the thread step out (line 47, tracer.mm). I understand I might need to use 
> something called ThreadPlans here, although besides SBThreadPlan.h, I can't 
> seem to find any examples of that class anywhere in the repo. I tried 
> stepping out when not in the breakpoint callback but that didn't seem to work 
> either.
> 
> (I did come across a python example here : 
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/scripted_step.py 
> but I'm not sure how I can combine that with a non-interactive debug session 
> approach I'm trying to use here)
> 
> I'm using macOS Sierra and have linked my app to xcode's LLDB.framework.
> 
> I'd be grateful if someone could help me out. Thank you!
> 
> - Bibhas
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to