forked from Imagelibrary/binutils-gdb
DAP: Handle "stepOut" request in outermost frame
Previously a "stepOut" request when in the outermost frame would result in a sucessful response even though gdb internally would reject the associated "finish" request, which means no stoppedEvent would ever be sent back to the client. Thus the client would believe the inferior was still running and as a consequence reject subsequent "next" and "stepIn" requests from the user. The solution is to execute the underlying finish command as a background command, i.e. `finish &`. If we're in the outermost frame an exception will be raised immediately, which we can now capture and report back to the client as success=False so then the absence of a `stopped` event is no longer a problem. We also make use of the `defer_stop_event` option to prevent a stop event from reaching the client until the response has been sent. Approved-By: Tom Tromey <tom@tromey.com>
This commit is contained in:
committed by
Tom Tromey
parent
42dc1b7f62
commit
61e608693b
@@ -73,10 +73,10 @@ def step_in(
|
||||
exec_and_expect_stop(cmd)
|
||||
|
||||
|
||||
@request("stepOut", response=False)
|
||||
@request("stepOut", defer_stop_events=True)
|
||||
def step_out(*, threadId: int, singleThread: bool = False, **args):
|
||||
_handle_thread_step(threadId, singleThread, True)
|
||||
exec_and_expect_stop("finish")
|
||||
exec_and_expect_stop("finish &", propagate_exception=True)
|
||||
|
||||
|
||||
# This is a server-side request because it is funny: it wants to
|
||||
|
||||
Reference in New Issue
Block a user