From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: "gdb-patches@sourceware.org ml" <gdb-patches@sourceware.org>
Subject: RFA: remote.c : allow long monitor cmds + allow user to C-c
Date: Mon, 23 Jan 2012 09:42:00 -0000 [thread overview]
Message-ID: <1327265676.23561.25.camel@soleil> (raw)
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 below 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.
Regression tested on linux x86, with and without gdbserver.
Ok to apply ?
Philippe
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.13761
diff -r1.13761 ChangeLog
0a1,5
> 2012-01-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
>
> * remote.c (remote_rcmd): use getpkt_sane to detect timeout
> and continue the loop. Add QUIT statement.
>
Index: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.478
diff -r1.478 remote.c
8585a8586
> QUIT; /* Allow user to bail out with ^C. */
8587c8588,8596
< 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;
> }
next reply other threads:[~2012-01-22 20:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 9:42 Philippe Waroquiers [this message]
2012-01-23 12:43 ` Pedro Alves
2012-01-23 21:09 ` Philippe Waroquiers
2012-01-24 4:43 ` Sergio Durigan Junior
2012-01-24 4:52 ` Philippe Waroquiers
2012-02-02 22:13 ` (ping) " Philippe Waroquiers
2012-02-03 20:28 ` Stan Shebs
2012-02-03 22:39 ` Philippe Waroquiers
2012-02-06 19:38 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1327265676.23561.25.camel@soleil \
--to=philippe.waroquiers@skynet.be \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox