You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change ThreadPlanStepOut::ShouldStop to only stop when we've hit
the breakpoint. Being in the correct stack frame is not sufficient.
Fixing the case of hitting a breakpoint on the last instruction of
a function and doing `finish`. A ThreadPlanStepOut is pushed, the
thread is set to eStateRunning, and then because we're at a breakpoint
site that we've hit, a ThreadPlanStepOverBreakpoint is pushed on
the thread plan stack. It sets itself to AutoContinue==true because
the thread state is eStateRunning.
We instruction step past the breakpoint, stop with stop reason
`trace`. ThreadPlanStepOverBreakpoint has completed, and it says
that we should AutoContinue. ThreadPlanStepOut detects that it is
now in the stack frame it wanted to step to -- does not check whether
it hit its breakpoint -- and pulls it self off the stack, removes
its breakpoint.
We resume execution via the ThreadPlanStepOverBreakpoint's AutoContinue,
and there is now no breakpoint for ThreadPlanStepOut - we lose
control of the process.
Instead, until we hit the ThreadPlanStepOut breakpoint, we say that
it has not completed. So now in this scenario of a breakpoint hit on
the last instruction and "finish", we instruction step, then continue
the thread and immediately hit the ThreadPlanStepOut breakpoint that
we're sitting at (but have not yet executed).
This fixes the llvm-mingw test failure that Martin reported, and I
captured in the new API test TestEmptyFuncThreadStepOut.py.
0 commit comments