From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31111 invoked by alias); 22 Jan 2012 20:54:48 -0000 Received: (qmail 31097 invoked by uid 22791); 22 Jan 2012 20:54:47 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailrelay009.isp.belgacom.be (HELO mailrelay009.isp.belgacom.be) (195.238.6.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Jan 2012 20:54:34 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAI92HE/ZiFo4/2dsb2JhbAAMN4UJrDwEgQcCJgJfE65wkG6BL4JPhxKBFgSnaA 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; 22 Jan 2012 21:54:32 +0100 Subject: RFA: remote.c : allow long monitor cmds + allow user to C-c From: Philippe Waroquiers To: "gdb-patches@sourceware.org ml" Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Jan 2012 09:42:00 -0000 Message-ID: <1327265676.23561.25.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/msg00758.txt.bz2 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 > > * 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; > }