jimingham wrote: > > 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. > > Fair point, but AFAIK with all these backends when you try to change state in > a situation where that's not allowed, you just get an error from the backend. > The gdbserver protocol doesn't tell you in advance whether that will be > possible. I don't think this impacts LLDB really, as long as you don't crash > when a state change fails. > > > 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. > > FWIW rr doesn't support this workflow, but UndoDB does. > > > 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. > > In this case, I think ThreadPlanStepOverRange will just resume with a > forward-continue packet. The backend continues forward through the recorded > history until it reaches the end of the history, i.e. the current state of > the stopped debuggee. Then it automatically resumes the debuggee and keeps > going. There is no need for a ThreadPlanTakeMeToThePresent.
It's good that that's not needed. If it ends up being needed, it would be trivial to add anyway. > > > 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. > > I think we'll need to have per-plan directions in some way, yes, but not > "reset to the present". And I don't think we need per-direction plans in this > PR. Since we really are in the end going to be instructing thread plans, I think explicitly passing the direction to the thread plans when you make them models better what you are doing. So I do prefer passing the directions as your current patch does than adding a global "SetDirection" method. As it stands, this will allow "reverse continue to a breakpoint", right? But once "in the past" you wouldn't be able to do either forward or reverse steps, you are just going to navigate by breakpoint? I'm just asking to clarify. That seems like a fine first stage. https://github.com/llvm/llvm-project/pull/99736 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
