jimingham wrote: This seems an okay solution for now. We really don't want to miss breakpoint hits if we can at all avoid it.
This isn't a regression, it's just one case where the proposed enhancement to stepping doesn't enhance stepping. We haven't had many (any?) reports of single stepping over a breakpoint blocking because we're running only one thread. Mostly that's because the actual instructions that might block are in system libraries that people tend to `next` over. Note, there's no inherent problem with the instruction we're stepping over not returning, it's only an issue if WE cause it to not return. By "block" we really mean "artificially block because the thread that should have caused the return was suspended by lldb". So this would have to be something like a read that was expecting another thread in the program to be the writer, which also limits the scope of the problem. In any case, if we are going to implement true "non-stop" debugging we will need to avoid the "remove and replace instructions" dance and instead leave the traps always in place. Since we are contractually obligated not to stop the other threads from the outside, that's the only way we can avoid missing breakpoint hits. We'll have to come up with some scheme to execute the instruction that was under the breakpoint out of place, so that we never have to remove the traps. At that point, ThreadPlanStepOverBreakpoint will be fine with running the other threads, and this problem will go away. https://github.com/llvm/llvm-project/pull/104532 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
