From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15055 invoked by alias); 23 Jan 2012 20:27:15 -0000 Received: (qmail 15043 invoked by uid 22791); 23 Jan 2012 20:27:14 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailrelay005.isp.belgacom.be (HELO mailrelay005.isp.belgacom.be) (195.238.6.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jan 2012 20:27:00 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAN6/HU/ZiFo4/2dsb2JhbAAMNoUJrBgBAQEEIwRSEAsOCgICJgICVwYTGq5qkTeBL4JPhxKBFgSnaA Received: from 56.90-136-217.adsl-dyn.isp.belgacom.be (HELO [192.168.1.3]) ([217.136.90.56]) by relay.skynet.be with ESMTP; 23 Jan 2012 21:26:58 +0100 Subject: Re: RFA: remote.c : allow long monitor cmds + allow user to C-c From: Philippe Waroquiers To: Pedro Alves Cc: "gdb-patches@sourceware.org ml" In-Reply-To: <4F1D5335.3090705@redhat.com> References: <1327265676.23561.25.camel@soleil> <4F1D5335.3090705@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Jan 2012 21:09:00 -0000 Message-ID: <1327350423.2215.6.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00793.txt.bz2 On Mon, 2012-01-23 at 12:31 +0000, Pedro Alves wrote: > Please use "cvs diff -up", or put "diff -up" in your ~/.cvsrc file. Oops, 2nd trial. 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 long 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 the one of 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 -u -p -r1.13761 ChangeLog --- gdb/ChangeLog 20 Jan 2012 10:31:25 -0000 1.13761 +++ gdb/ChangeLog 23 Jan 2012 20:22:22 -0000 @@ -1,3 +1,8 @@ +2012-01-22 Philippe Waroquiers + + * remote.c (remote_rcmd): use getpkt_sane to detect timeout + and continue the loop. Add QUIT statement. + 2012-01-20 Ulrich Weigand * NEWS: Document remote "info proc" and "generate-core-file". Index: gdb/remote.c =================================================================== RCS file: /cvs/src/src/gdb/remote.c,v retrieving revision 1.478 diff -u -p -r1.478 remote.c --- gdb/remote.c 20 Jan 2012 09:47:32 -0000 1.478 +++ gdb/remote.c 23 Jan 2012 20:22:24 -0000 @@ -8583,8 +8583,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."));