[Lldb-commits] [lldb] [lldb] Clear Frames when changing `disable-language-runtime-unwindplans` (PR #151208)

Felipe de Azevedo Piovezan via lldb-commits lldb-commits at lists.llvm.org
Wed Jul 30 07:47:03 PDT 2025


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


More information about the lldb-commits mailing list