From 61e608693b53a13c48d509a45b329f7ef9dfaa19 Mon Sep 17 00:00:00 2001
From: Johan Sternerup <johan.sternerup@gmail.com>
Date: Sat, 1 Jun 2024 18:16:32 +0200
Subject: 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>
---
gdb/python/lib/gdb/dap/next.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
(limited to 'gdb/python/lib')
diff --git a/gdb/python/lib/gdb/dap/next.py b/gdb/python/lib/gdb/dap/next.py
index 1dc1d6d..7e06b1b 100644
--- a/gdb/python/lib/gdb/dap/next.py
+++ b/gdb/python/lib/gdb/dap/next.py
@@ -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
--
cgit v1.1