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
[Dexter] Use continue when resuming lldb execution to reach breakpoint (#156481)
Currently, Dexter's interface for lldb and lldb-dap has a post-step hook
that checks to see whether lldb reports that we stopped because we
completed a step, and if so checks to see whether the current $pc
address also matches a known breakpoint whose conditions (if any) are
met, and if so it requests to "step in", so that we "resume" execution,
stopping again at the current address, such that lldb now reports that
we have hit a breakpoint and provides the list of breakpoints that were
hit.
This logic has a flaw however: the call to "step in" sets an implicit
breakpoint on the next line. In Dexter's default stepping mode this is
not an issue, as we intend to step there eventually. When we use
DexContinue, however, we set a breakpoint from which we wish to continue
to the next user-specified breakpoint, rather than stepping. Currently,
there is a bug where Dexter sets a DexContinue breakpoint, arrives at
that bp from a step, requests "step in" so that LLDB gives us the hit
breakpoint ID, requests "continue" to hit the next user breakpoint, and
then arrives at the next line after the continue due to the earlier
"step in" request. This effectively negates the DexContinue command.
This patch fixes this behaviour by using "continue" instead of "step in"
in the post-step hook, ensuring that no implicit breakpoint is set so
that we do not incorrectly stop at the next line.
0 commit comments