From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83403 invoked by alias); 27 May 2018 21:19:45 -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 82692 invoked by uid 89); 27 May 2018 21:19:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=initiated, gdbpatches, H*u:1.3.6, H*UA:1.3.6 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 May 2018 21:19:42 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w4RLJaCR023067 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 27 May 2018 17:19:41 -0400 Received: by simark.ca (Postfix, from userid 112) id 43D821F21C; Sun, 27 May 2018 17:19:36 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 7BA8D1EF61; Sun, 27 May 2018 17:19:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 27 May 2018 21:19:00 -0000 From: Simon Marchi To: Jan Vrany Cc: gdb@sourceware.org Subject: Re: Breakpoint locations, enableness and MI's =breakpoint-modified event In-Reply-To: References: Message-ID: <4fa6d696191ab3200cc9ef1a6bee7206@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sun, 27 May 2018 21:19:36 +0000 X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00025.txt.bz2 On 2018-05-23 06:14, Jan Vrany wrote: > Hi there, Hi Jan, > when using MI, an MI event =breakpoint-modified is emitted if > breakpoint > enableness is changed via CLI command (such as 'dis 1'). However, if > breakpoint location is changed (such as 'dis 1.1'), no event is emitted > so the frontend may get out of sync. That sounds like a bug. > Is there any reason for this? > Also, why the event is not emitted when breakpoint enablement is > changed via MI command -break-enable? Changes directly initiated by the MI frontend do not generate MI events towards that frontend. When the frontend receives the successful response to its command, it already knows that the change went through. If there are multiple MI channels (created using the new-ui command), the MI frontends other than the one that sent the command should receive the event. That doesn't seem to work either, I would consider that a bug. > In case this is a bug, I tried to fix it and emit the event even for > breakpoint location changes (see the patch below, testcase included). > In short, I have extended gdb::observers::breakpoint_modified to take > also the location (or nullptr) and notify() it also when location > enableness changes, passing the specific location. The MI hook is > updated accordingly, the rest is left as it was. Other uses of > gdb::observers::breakpoint_modified may need to be updated too (python, > guile & tui comes to mind). > > Best, Jan Thanks, I'll reply with comments about the patch in another message where I CC gdb-patches@ instead of gdb@. Simon