jimingham wrote: > @jimingham I was looking into popping all StepOverBreakpoint plans and > recreating them fresh each WillResume, but ran into two issues: > > 1. DidPop() side effect: Popping calls DidPop() -> ReenableBreakpointSite(), > which would either re-enable the breakpoint directly or go through the > deferred tracking path. We'd need to suppress this during cleanup probably.
For the threads that have had "RegisterSteppingOverBreakpointTrap" called on them, you could use the fact that they were being popped in that state to tell you that you don't need to re-insert the trap in DidPop. But that would still cause a bunch of removal and reinsertions for breakpoints that were only hit once at the current stop. You could fix that by only removing the plans for threads that are registered (and again using registry to mean "don't reinsert trap".) But then you'd still have to treat those differently, and I'm not sure the algorithm would be cleaner. > 2. The trap distinction: SetupToStepOverBreakpointIfNeeded checks > m_stopped_at_unexecuted_bp != thread_pc to distinguish "thread arrived at > breakpoint but hasn't executed the trap" from "thread already hit the > breakpoint and needs to step over." While m_stopped_at_unexecuted_bp lives on > the Thread (so it survives plan popping), I am not confident it stays correct > through a pop/recreate cycle (maybe I'm wrong?), if any codepath clears or > updates it during plan destruction, we could end up either skipping a > step-over or double-counting a breakpoint hit. For the threads that don't yet have ThreadPlanStepOverBreakpoint plans in place, you will be able to compute this correctly from the stop reason - if it was "no reason" then the thread stopped at the breakpoint location BEFORE executing the trap, and if it is "SIGTRAP" it has hit it... So you only have to ensure that you put ThreadPlanStepOverBreakpoint plans on threads that had them at the beginning of WillResume. So you would have to build a list of the threads that had "ThreadStepOverBreakpoint" traps in place, and agree to always put a ThreadPlanStepOverBreakpoint on them as you are scanning threads. > > If this issues can be address, I don't care to use this approach instead. Do > you have a suggestion for how to cleanly suppress the DidPop() re-enable and > ensure the trap distinction is preserved through a pop/recreate cycle? I'm beginning to think this wouldn't be simpler, what do you think? https://github.com/llvm/llvm-project/pull/180101 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
