OpenE2K/binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

The remote stub can implement monitor commands which are not

Browse Source 
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.
This commit is contained in:
Philippe Waroquiers 2012-02-03 22:52:32 +00:00
parent 2c175ebc74
commit 5b37825d84
2 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/ChangeLog
View File

@ -1,3 +1,8 @@
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:

11
gdb/remote.c
View File

@ -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."));