From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27494 invoked by alias); 18 Jun 2019 03:14:27 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27486 invoked by uid 89); 18 Jun 2019 03:14:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=arguing, skeptical, UD:p.m, H*M:5457 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Jun 2019 03:14:25 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id EDF321E05A; Mon, 17 Jun 2019 23:14:22 -0400 (EDT) Subject: Re: MI3 and async notifications To: Jan Vrany , "gdb@sourceware.org" References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> Cc: Joel Brobecker , Tom Tromey , =?UTF-8?B?QW5kcsOpIFDDtm5pdHo=?= , Jonah Graham From: Simon Marchi Message-ID: <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca> Date: Tue, 18 Jun 2019 03:14:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00048.txt.bz2 On 2019-06-10 5:19 p.m., Jan Vrany wrote: > Hello, > > as an user og GDB/MI (and frontent developer), I'd like to > open a discussion about one aspect of MI that I'd like to change > in MI3 before it is released into the wild. Hi Jan and others, Thanks, nice to see some action on improving MI. I have just read the thread, and I have a few questions about where this is going. > Currently, quite a few commands suppress async notifications when > a command is issued through MI. For example, when a breakpoint is > added using -break-insert then =breakpoint-created is not emitted. > > At least in my case, this behavior complicates client design because > now the client has to care for new breakpoints on multiple places: > (i) listen to breakpoint created events to handle cases where breakpoint > is added via CLI. > (ii) do similar processing whenever MI returns ^done for previously > issued -break-insert command. > > This leads to a complex logic, especially in cases where frontend has > some scripting support (so execution of MI commands is not completely > under frontend developer's control). > > Emitting notifications unconditionally would simplify things a lot > - again at least in my case. The idea of the current behavior is that you shouldn't be asynchronously notified of the result of your own command. As was illustrated in this thread, it would be difficult to determine whether a =breakpoint-created async notification is the result of the pending -break-insert, or it just happens that the user has created a breakpoint on the CLI at the same time. So to remove this ambiguity, we don't send the notification. I am skeptical about the complex logic you are talking about to handle both =breakpoint-created notifications and responses to the -break-insert. Both contain pretty much the same information. So rather than adding an option in GDB for emitting async notifications unconditionally, can't you just process both using the same function? That doesn't really complicated, but maybe I am misunderstanding your problem, in which case please expand. It would be useful to have a very concrete use case where you could point out "see here, I am missing some info and a notification would be useful". It could very well be that some notifications are just missing. For example I would argue we are missing notifications if using two MI clients (through the new-ui command, although I don't remember if that's "officially" supported). If one of the MI client inserts a breakpoint with -break-insert, the other one is not notified. I would consider that a bug that the second client doesn't get a =breakpoint-created. Also, I am a bit worried by a proposal in the thread, which would be to remove information from the -break-insert ^done response, arguing that the async notification would have already been emitted. It is clear and unambiguous how to map a response to a request, but it would not be obvious to map an async notification to a request. So it appears to me as a regression in functionality. Simon