"C++ SB API : Stepping out within a breakpoint callback"

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

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