From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20286 invoked by alias); 2 Jun 2015 15:12:26 -0000 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 Received: (qmail 20274 invoked by uid 89); 2 Jun 2015 15:12:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout25.012.net.il Received: from mtaout25.012.net.il (HELO mtaout25.012.net.il) (80.179.55.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jun 2015 15:12:24 +0000 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NPB00E00OMIX600@mtaout25.012.net.il> for gdb-patches@sourceware.org; Tue, 02 Jun 2015 18:06:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NPB00CRAON4SV20@mtaout25.012.net.il>; Tue, 02 Jun 2015 18:06:40 +0300 (IDT) Date: Tue, 02 Jun 2015 15:12:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] [RFC] Discard local stdin events while an attached inferior is running In-reply-to: <1433252358-26692-1-git-send-email-patrick@parcs.ath.cx> To: Patrick Palka Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fv6arvrm.fsf@gnu.org> References: <1433252358-26692-1-git-send-email-patrick@parcs.ath.cx> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00026.txt.bz2 > From: Patrick Palka > Cc: Patrick Palka > Date: Tue, 2 Jun 2015 09:39:18 -0400 > > This patch attempts to work around an annoying typo that I (and others, > I assume) commonly make while debugging an attached (not forked) > process. That is, I sometimes type "continue\n\n" instead of > "continue\n" when I want to resume the inferior. By doing so, the > inferior gets resumed and the extraneous "\n" gets buffered. But once > GDB regains control, the extraneous "\n" gets read and so an empty > command line is submitted to readline. This is shorthand for running > the previous command again. So effectively typing "continue\n\n" will > run "continue" twice. Running "continue" twice instead of once can have > irreversible consequences to the debugging session and thus is pretty > annoying to deal with. > > To work around this kind of typo, this patch installs a dummy event > handler that discards all local stdin events that occur when the > attached inferior is (synchronously) running. > > The obvious side-effect of this patch is that dexterous users can no > longer "queue" commands while an attached inferior is running, e.g. > type "continue\nprint foo" with the intention of "print foo" being run > as soon as GDB regains control. I personally don't make use of this > ability very much. IMO, this incompatible change of behavior should at least have an option to get the old behavior back, and that option should possibly be off by default. In any case, there should be a NEWS entry and a patch for the manual which describe this unusual feature. > Is this typo a common occurrence for anyone else? Not common, but sometimes. However, I sometimes type ahead future commands without waiting for the prompt, for example, when I know I'll need a lot of CR presses.