felipepiovezan wrote: > 1. Do we need to unset the Currently Selected Frame, we've almost surely > invalidated it, and even if it does happen to accidentally still exist, it > might mean something different. This almost seems like something > ClearStackFrames should do.
Based on the implementation of `Thread::SetSelectedFrame`, the selected frame is a property of `Thread::m_curr_frames_sp`, which gets freed by `Thread::ClearStackFrames`. I did an experiment where I stopped a test program, selected `frame 1`, then updated the setting. Then I did a `frame` command, and what was shown was frame 0. So I think we are indeed properly reseting the selected frame. > 2. This probably works, but to be sure... What happens if I run a function > by hand, stop in a breakpoint in that function, then set this setting to undo > all the cached stack frames. Do we have enough info in that case to > reconstruct the frames we've pushed on the stack and continue the execution? Do you mean something like: ``` b some_foo expr --ignore-breakpoints false -- some_foo() settings set target.process.disable-language-runtime-unwindplans true thread return -x ``` This seems to work too. What will obviously be bad is if a user starts a step-over operation, hits a breakpoint along the way, flips (but doesn't unflip!) this flag in a way that _actually_ changes the backtrace, and then attempts to `continue`. This will definitely confuse the in-flight step-over operation, but it is not related to this patch. https://github.com/llvm/llvm-project/pull/151208 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
