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.
+2012-02-03 Philippe Waroquiers <philippe.waroquiers@skynet.be>
+
+ * remote.c (remote_rcmd): Use getpkt_sane to detect timeout
+ and continue the loop. Add QUIT statement.
+
2012-02-03 Tom Tromey <tromey@redhat.com>
PR gdb/13596:
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."));