jingham added a comment. This looks fine to me.
The thread plans are self-healing, in the sense that they always check after every stop whether they are still relevant, (IsStale) and unship themselves if they aren't. For instance, if a step-over plan finds that the stack has unwound past its target frame, it will pop itself. The way to actively handle exceptions and longjmp and the like currently is to put breakpoints on them by hand, and then you will get to see the state before the unwinding. I haven't done that automatically in the thread plans because I don't have a way of knowing whether the exception throw will unwind past the last stack frame of interest to the thread plans, and it would be annoying to have stepping stop all the time to tell you about exceptions you don't care about. It's better to let the users do this by hand. One missing piece of lldb functionality is the ability to analyze these exceptional stack events and predict their results at the throw point. This should be possible for C++ at least using the Itanium ABI for exception throwing, since you would just be replaying the scan pass of the exception handling. Once that is in place, then you could always stop on exceptions, but ignore all the ones that would get caught before the first frame of interest, and stop for ones that would throw past it. gdb used to handle longjmp by always breaking on setjmp and reading out the target of the jump. We could also do that, but TTTT, I have had people complain about exceptions losing control of stepping, but I haven't had anybody bring up setjmp/longjmp for quite a while. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76216/new/ https://reviews.llvm.org/D76216 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
