jimingham wrote:
> On Jul 22, 2024, at 2:56 PM, rocallahan ***@***.***> wrote: > > > @rocallahan commented on this pull request. > > In lldb/source/Target/Process.cpp > <https://github.com/llvm/llvm-project/pull/99736#discussion_r1687181703>: > > > @@ -3264,6 +3266,11 @@ Status Process::PrivateResume() { > // filters before resuming. > UpdateAutomaticSignalFiltering(); > > + if (m_last_run_direction != direction) { > If the user does "continue", hits a breakpoint, does "reverse-step", and then > "reverse-continue" presumably we do have to abandon the original "continue". > Since this patch only implements "reverse-continue" maybe always abandoning > the thread plans is actually the right thing to do for now? > "Continue" isn't a persistent operation for thread plans. The thing that would be "persistent" in this case would be the "ThreadPlanStepOverRange(forward)" plan which the "next" operation pushed on the stack. When you hit the breakpoint, that plan was asked "did you explain this stop" - the answer to that was "no" this was just a random breakpoint hit. It was asked also "are you done" - the answer to which was still no since the next-ing frame is still on the stack, and finally "are you stale - no longer relevant" but the frame is still on the Thread's stack, so that was answered "false" the "ThreadPlanStepOverRange stayed on the ThreadPlan stack. Then in my scenario I did a couple of forward steps, and some "reverse steps". At each point the next plan was asked the same question, and so long as that StackFrame is still on the thread stack, the plan stays active. If you did a reverse-continue that stopped when the process is in a state where the next-ing StackFrame is no longer on the stack, that plan will return "false" to the "is stale" question and get popped at that point. But so long as the reverse continues stays in the time-line where that frame is on the stack, we should honor the user intentions that came with it. There are some things you will have to do to make all this really work (for instance, a "forward-next" plan can't explain stops from backward execution, so the plans will have to know about that. As I said on another thread, I think you will have to make the plans cooperate with forward and backward behavior at some point. But for this patch it's fine to not allow that mixing, and in that case it is probably best to just dump all the extant and dumpable plans. You might have to be careful in the case where someone runs a function call, stops at a breakpoint in the function call and decides to go backwards in the function execution (if that's possible). Dumping the function plan removes the function calling frames from the stack, so if you throw away that plan you will end up exiting the function call - which wasn't what the user expected. Jim > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/99736#discussion_r1687181703>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVW7PMAASCC4KYT6KBBDZNV5ZHAVCNFSM6AAAAABLFTBQAKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCOJSGYYTKOJTGU>. > You are receiving this because you are on a team that was mentioned. > 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
