[Lldb-commits] [lldb] [lldb] Implement basic support for reverse-continue (PR #112079)

[via lldb-commits]

jimingham wrote:

> Ok, tell me what you think of this proposal:
> 
> 1. Each thread plan has a virtual `GetDirection()` method returning `RunDirection`. Existing plans other than `ThreadBasePlan` return `eRunForward`.
> 2. There is a per-process `base direction` flag. `ThreadBasePlan::GetDirection()` returns the value of that flag. Defaults to `eRunForward`.
> 3. There is a new `SBProcess::ContinueInDirection(direction)` method. This method updates the "process base direction" flag. For simplicity, for now, _if the base direction changed_, pop all plans on all threads.
> 4. `SBProcess::Continue()` is unchanged, i.e. preserves the base direction.
> 5. When we resume execution:
>    5a) If we choose to resume a single runnable thread whose current plan has `StopOthers()` , just resume using that plan's direction.
>    5b) Otherwise use the process base direction, and before resuming, pop plans until all threads' current plans match that direction.
> 
> I think this is fairly simple while behaving much like what you suggest. It doesn't require introducing a new kind of `ThreadPlan` which is good. I think it can extend cleanly to support reverse-step etc.

In the long run, I really hope we can do without the restriction that before continuing we have to make sure the thread plan stacks of all "RunOthers" thread plans are homogeneous in direction.  

But I don't think you will be able to have heterogenous in direction stacks without having something to coordinate the direction switch - and IMO the best way to do that will require a new thread plan and its management.  

So as a first cut, the homogeneity restriction seems like an okay tradeoff to reduce implementation complexity.  

Note that the direction switching plan as I described would operate like a "base thread plan" - it would absorb all the unexplained events instead of passing them to the other direction plans above it.  So having the base thread plan in charge of the direction of the stack should naturally extend to the more complex situation where we have base-thread-like marker plans in the middle of the plan stack.  You'd get the direction from the youngest base thread derived plan on the stack, rather than the one in the first slot.  There's already precedence for using intermediate base plans in RunThreadPlan where we use a stopper base thread plan to keep events from going to the rest of the plan stack when we find ourselves running an expression on the private state thread.

At the SB level, "ContinueInDirection" is fine - all the Execution Control API's actually restart the process.  But at the lldb_private layer I'm guessing we'll want a "SetDirection" and then the standard Continue.  The problem with ContinueInDirection is that it means I can't make a decision about the direction I want the process to go until I'm ready to actually continue the process.  It's been really handy to have the "Push a thread plan" gesture indicate what the next stage in execution control will do without having to immediately resume, and I think we'll want that for changing direction as well.


https://github.com/llvm/llvm-project/pull/112079