The remote stub can implement monitor commands which are not

known by gdb. Such monitor commands can take a long time
to execute. An example of this is the "leak_search" monitor
command implemented in the Valgrind gdbserver.

Currently, gdb will timeout on such a monitor command.
The remote stub however will continue to execute the
command and send the output later. Gdb and the remote
stub can then be desynchronised : gdb sends a packet,
and the reply read from the stub is a previous packet.

The change committed uses getpkt_sane to detect a timeout.
In this case, it continues the loop.
A QUIT; is inserted in the loop to allow the user
to stop handling the current command. possibly
still creating a desynchronisation between gdb and the stub
but that will be upon user request.

1 files changed, 10 insertions, 1 deletions

diff --git a/gdb/remote.c b/gdb/remote.c
index 1c37b69..3187ac0 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -8590,8 +8590,17 @@ remote_rcmd (char *command,
       char *buf;
 
       /* XXX - see also remote_get_noisy_reply().  */
+      QUIT;			/* Allow user to bail out with ^C.  */
       rs->buf[0] = '\0';
-      getpkt (&rs->buf, &rs->buf_size, 0);
+      if (getpkt_sane (&rs->buf, &rs->buf_size, 0) == -1)
+        { 
+          /* Timeout.  Continue to (try to) read responses.
+             This is better than stopping with an error, assuming the stub
+             is still executing the (long) monitor command.
+             If needed, the user can interrupt gdb using C-c, obtaining
+             an effect similar to stop on timeout.  */
+          continue;
+        }
       buf = rs->buf;
       if (buf[0] == '\0')
 	error (_("Target does not support this command."));