From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13920 invoked by alias); 20 Jun 2019 20:46:15 -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 13731 invoked by uid 89); 20 Jun 2019 20:45:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:5687f16, H*i:sk:5687f16 X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jun 2019 20:45:56 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [IPv6:2001:718:2:2901:0:0:0:238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id x5KKjQ0s094072 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Jun 2019 22:45:28 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Received: from [IPv6:2a02:c7d:2fcb:c700:6267:20ff:fee4:3e2c] ([IPv6:2a02:c7d:2fcb:c700:6267:20ff:fee4:3e2c]) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id x5KKjO2W033636 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 20 Jun 2019 22:45:25 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: Subject: Re: MI3 and async notifications From: Jan Vrany To: Simon Marchi , "gdb@sourceware.org" Cc: Joel Brobecker , Tom Tromey , =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= , Jonah Graham Date: Thu, 20 Jun 2019 20:46:00 -0000 In-Reply-To: <5687f162-d938-7eff-55ba-cf72d9d91e58@simark.ca> References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca> <70be86e627f6ec578217f01df9af914080b181c2.camel@fit.cvut.cz> <5687f162-d938-7eff-55ba-cf72d9d91e58@simark.ca> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00065.txt.bz2 On Thu, 2019-06-20 at 11:31 -0400, Simon Marchi wrote: > > Ok, then I understand how ugly it is to try to track the commands and their responses. I would tend to > say that it falls in the category "you're not using it the way it was intended to": Fair enough :-) > > I am still unsure about emitting events unconditionally. For example: some frontends want to > insert "internal" breakpoints, which are breakpoints that are not going to be directly shown to > users. They send a -break-insert and decide that the breakpoint which results from this won't be > propagated to the UI. But breakpoint async events are propagated to the UI (presumably because > they originate from the user creating a breakpoint in the CLI). If GDB now emits an event for > the -break-insert breakpoint, the frontend can't know right away which future =breakpoint-created > event it should ignore. Again, it would need to buffer all =breakpoint-created events until it > gets the ^done, then let pass through all events except the one that matches the created breakpoint. > Yeah, that would be tricky. Okay, it looks I lost this case. That's fine. Thanks! Jan