From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49611 invoked by alias); 17 Jun 2019 13:12:23 -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 49598 invoked by uid 89); 17 Jun 2019 13:12:23 -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=respond 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 13:12:17 +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 x5HDC85b065942 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Jun 2019 15:12:10 +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 x5HDC7oZ039526 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 17 Jun 2019 15:12:08 +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" Date: Mon, 17 Jun 2019 13:12:00 -0000 In-Reply-To: <20190617125638.GA6859@adacore.com> References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <871rzu9at0.fsf@tromey.com> <20190617121412.GA4157@adacore.com> <20190617125638.GA6859@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/msg00041.txt.bz2 On Mon, 2019-06-17 at 08:56 -0400, Joel Brobecker wrote: > > I do agree, avoid the extra configurability - but I simply don't know how > > to work with just async notifications to sync messages. It means that CDT > > will have to issues the -break-insert, look for the done message and > > "search" between them to find the =breakpoint-created that matched and > > separately process any that don't. Please see my earlier message about how > > to handle race condition between -break-inserts over MI and breaks inserted > > from CLI. This race condition does not happen during normal operation > > (where a human is driving everything) but does kick in during many > > semi-automated flows. Perhaps this isn't a big problem, but to me it seems > > the logic to match up -break-insert to =breakpoint-created in client side > > is complex and bug prone. > > The part I don't understand is why it matters to sync the two. > 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? Also note that this is not only about breakpoints but also about things like -gdb-set and few others. Jan