From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44804 invoked by alias); 10 Feb 2017 17: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 44775 invoked by uid 89); 10 Feb 2017 17:12:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=sk:modify-, sk:modify, H*f:sk:8990475, H*f:sk:e03e55a 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:12:24 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 43F0EC04B946; Fri, 10 Feb 2017 17:12:24 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1AHCLTa018899; Fri, 10 Feb 2017 12:12:22 -0500 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: Date: Fri, 10 Feb 2017 17:12: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/msg00266.txt.bz2 On 02/10/2017 04:52 PM, Simon Marchi wrote: > On 2017-02-10 11:48, Pedro Alves wrote: >> On 02/10/2017 04:36 PM, Simon Marchi wrote: >>> We have a little problem in Eclipse CDT related to queries being sent on >>> the MI channel. GDB sends queries on the MI stream and waits for an >>> answer (y or n), but since CDT will never answer, it causes a deadlock. >>> >>> Note that this is only a problem when using MI as a side-channel >>> (new-ui) on a dedicated tty. It doesn't happen if GDB's input/output >>> streams are pipes, for example. In that case, the queries are >>> auto-answered as they should. >> >> I think we could have a testsuite test for this, as the 'new-ui'-related >> testcases create a pty for the secondary MI channel ("separate-mi-tty")? > > Right, I didn't think of making a test, I'll work on it. I'll try to > find a query that's easier to trigger than the > modify-memory-while-replaying one though. 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. In this case, instead of: query (_("Because GDB is in replay mode, changing the " "value of a register will make the execution " "log unusable from this point onward. " "Change all registers?")); we'd error here with something like: Cannot change the value of a register in replay mode, it would make the execution log unusable from this point onward. See whatnot. and then if users really want to change memory, they would use something like a "record discard" or "record commit" or some such command that discards history leaving the inferior state as it is right now (not sure there's a command that does that already.) In scripts and maybe frontends, you'd use the existing "set record memory-query off", renamed to "set record allow-memory-write on" or some such. Thanks, Pedro Alves