From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72854 invoked by alias); 17 Jun 2019 20:58:04 -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 72845 invoked by uid 89); 17 Jun 2019 20:58:04 -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=channel 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; Mon, 17 Jun 2019 20:58:01 +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 x5HKvqqU082025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Jun 2019 22:57:54 +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 x5HKvpYj052441 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 17 Jun 2019 22:57:52 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: Subject: Re: MI3 and async notifications From: Jan Vrany To: Joel Brobecker , Jonah Graham Cc: Tom Tromey , "gdb@sourceware.org" , =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= Date: Mon, 17 Jun 2019 20:58:00 -0000 In-Reply-To: <20190617204515.GB6859@adacore.com> References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <871rzu9at0.fsf@tromey.com> <20190617121412.GA4157@adacore.com> <20190617125638.GA6859@adacore.com> <20190617204515.GB6859@adacore.com> 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/msg00045.txt.bz2 On Mon, 2019-06-17 at 16:45 -0400, Joel Brobecker wrote: > > > Jonah, I was about to ask the same. I understand that you need to know > > > which breakpoint has been inserted by given command, but this > > > if we respond with something like > > > > > > 1-break-insert main > > > =breakpoint-created,bkpt={number="1",type=...} > > > 1^done,bkpt-number=1 > > > > > > then you just search for breakpoint with that id, no? Given that MI > > > guarantees that =breakpoint-created arrives before ^done reply to command. > > > Am I missing something? > > > > > > > No you aren't missing anything. That would be a perfectly acceptable > > solution for CDT. > > > > There would still be some other new logic needed for CDT, we would > > still have to store all the =breakpoint-created if there is a > > -break-insert active and then process all of them when the ^done is > > received. However that seems fairly reasonable. > > Do we even need the bkpt-number=1 attribute in the "done" command? > The notification includes that information, so the GUI should have > enough info from there to determine which UI element to update, right? > I think so. Imagine you have a UI with breakpoint list and there's an "Add Breakpoint" button. When "Add Breakpoint" is pressed, user fills location, press "OK", new breakpoint is added and *UI pre-selects just added breakpoint*. This is IMO sensible UI behavior. Now, when you press "OK" to add the breakpoint on a location, behind the scenes frontend issues -break-insert command and waits for ^done confirmation. But as Jonah mentioned, another breakpoint could be inserted meanwhile so you'd get something like this on MI channel. 10-break-insert main =breakpoint-created,bkpt={number="1",type=...} =breakpoint-created,bkpt={number="2",type=...} =breakpoint-created,bkpt={number="3",type=...} 10^done Now, if ^done response would not contain bkpt-number=2 attribute, how would you know which is the breakpoint you need to pre-select in the UI? Jan