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

[via lldb-commits]

jimingham wrote:



> On Jul 25, 2024, at 4:58 PM, rocallahan ***@***.***> wrote:
> 
> 
> Most of the execution control logic should just know "forward" and "backwards", but then whether those are implemented by using the reverse debugging machinery or by allowing the program to run for realz will be know deeper in the execution control machinery - most likely governed by the thread plans.
> 
> Actually LLDB is (and should be) oblivious to whether the gdbserver is running the program "for realz" or not.
> 
> When using rr, we currently never run the program "for realz" while the user is in a debugging session. The workflow is: a) record a program run and save the recording to disk b) replay the run with the debugger attached. During b), both forward and reverse execution are "on rails", only observing what happened during recording. (Ok, ignoring user-requested function calls made through the debugger for now.)
> 
> UndoDB and gdb's reverse execution are a bit different. They do support the workflow you're thinking of, where the program is actually "live" while you explore history in the past. But the distinction between "replaying through history" and "runinng live" is never surfaced in the gdbserver protocol and from the debugger's point of view I don't think it should matter.
> 
I'm not sure about that.  First off, for systems that do past motion and forward motion, there are things you really can't do effectively in the past, like set variable values and have that make any difference.  So we probably will need to know whether we're executing in the immutable past or the mutable present.

Also, I would like the following workflow to "just work".

I am running "for realz", and I do a forward "next" which hits a breakpoint before the next concludes.  I step over another function at that breakpoint.  I realize I wish I had stepped into it, so I do a "reverse next" - is that how you do it - or set a breakpoint in the function and reverse continue.  Then I step around in the past a bit till I see what I wanted to see.  Then I'm done with the past, and want to go back to the present.  Since the last persistent action I had done was the original next, then `continue` should take up that next (going forward) and complete it.  That is all pretty straightforward, the "TheadPlanStepOverRange" - which is the current plan on the plan stack - for that next knows it's going forward, so first it pushes a "ThreadPlanTakeMeToThePresent" and when that completes, it can continue with its forward motion.

So for systems that support live reverse debugging, I do think we'll need a "reset to the present" gesture, and plans will need to know whether they are operating on the past or present.

But I agree, for the most part we should only care about direction and not about where we currently are on the timeline.

Jim


> —
> Reply to this email directly, view it on GitHub <https://github.com/llvm/llvm-project/pull/99736#issuecomment-2251594245>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW7YNHATGQEELZYDBGTZOGGL5AVCNFSM6AAAAABLFTBQAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJRGU4TIMRUGU>.
> You are receiving this because you were mentioned.
> 



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