From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126389 invoked by alias); 10 Feb 2017 17:44:29 -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 126324 invoked by uid 89); 10 Feb 2017 17:44:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=notifications, unfinished, H*f:sk:8990475, asynchronous X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Feb 2017 17:44:13 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 98A3D7713; Fri, 10 Feb 2017 17:44:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id BD627B753C; Fri, 10 Feb 2017 17:44:12 +0000 (UTC) Subject: Re: [PATCH] Don't send queries to the MI interpreter To: Simon Marchi References: <20170210163650.10334-1-simon.marchi@ericsson.com> <89904751-7015-b272-98c1-33e786f7c356@redhat.com> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <85ae4ad9-acdc-c9ba-6606-a7ac2abc7e2e@redhat.com> Date: Fri, 10 Feb 2017 17:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00267.txt.bz2 On 02/10/2017 05:12 PM, Pedro Alves wrote: > I've run into these queries deep down in the record layer > in the past, and wondered about getting rid of them. > > Particularly this one: > > if (!yquery (_("Do you want to auto delete previous execution " > "log entries when record/replay buffer becomes " > "full (record full stop-at-limit)?"))) > error (_("Process record: stopped by user.")); > > In order to query, the inferior is already temporarily stopped. > So why not just unconditionally error, and lets user tweak > "set record stop-at-limit" and continue if they want. Let me expand on this a bit. I have a local unfinished branch somewhere that attempts to address the "pagination/queries in the primary CLI prevent MI async notifications (like *stopped) on the secondary MI channel" issue. I think there's a PR about it, but I can't find it now. It's the one that led to Eclipse disabling pagination. The issue is that pagination is handled by starting a new nested event loop deep inside the print that triggered the pagination, and while a secondary event loop is running, no target events are processed at all (see gdb_readline_wrapper, the target_async(0) call). So GDB will only notice that the inferior stopped for a trap when the pagination/query is unblocked. So the idea to address this was to continue processing target events in the background and send them to MI, even while the CLI is stopped in the pagination. Meanwhile, if some target event ends up producing _more_ output _while_ the CLI is already waiting for the user to request another page of output, we'd need to buffer the output somewhere temporarily, in order to later dump it on the screen when whatever we were outputting that paginated is fully flushed/output. This suggested actually always buffering asynchronous output and dumping it on the screen at a safe point. I.e., output generated inside handle_inferior_event would always go to a buffer, and then dumped on the screen after processing the event, when safe. And it is at this point that I thought that it is odd to query and ask for user input deep down inside the record layer, while handling some asynchronous execution event -- i.e., deep down inside handle_inferior_event. If we're buffering output, when the user won't see the query anyway. Hmm, now that I think of it, the "Do you want to auto delete previous execution" query wouldn't be converted to an error, but instead to a something like TARGET_WAITKIND_NO_HISTORY, I suppose. OK, I found the branch. Pushed here now: https://github.com/palves/gdb/commits/palves/console-pagination Thanks, Pedro Alves