From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59091 invoked by alias); 5 Jul 2019 19:35:56 -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 59083 invoked by uid 89); 5 Jul 2019 19:35:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=breakinsert, H*r:sk:gdb@sou, break-insert X-HELO: mail-wm1-f42.google.com Received: from mail-wm1-f42.google.com (HELO mail-wm1-f42.google.com) (209.85.128.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Jul 2019 19:35:55 +0000 Received: by mail-wm1-f42.google.com with SMTP id g67so4514181wme.1 for ; Fri, 05 Jul 2019 12:35:54 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4c97:6d52:2cea:997b? ([2001:8a0:f913:f700:4c97:6d52:2cea:997b]) by smtp.gmail.com with ESMTPSA id o1sm11085536wrw.54.2019.07.05.12.35.52 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 12:35:52 -0700 (PDT) Subject: Re: MI3 and async notifications To: Simon Marchi , Jan Vrany , "gdb@sourceware.org" 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> Cc: Joel Brobecker , Tom Tromey , =?UTF-8?B?QW5kcsOpIFDDtm5pdHo=?= , Jonah Graham From: Pedro Alves Message-ID: <068f994b-7613-28a4-8b57-3833bb0cc9d9@redhat.com> Date: Fri, 05 Jul 2019 19:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <5687f162-d938-7eff-55ba-cf72d9d91e58@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-07/txt/msg00000.txt.bz2 On 6/20/19 4:31 PM, Simon Marchi wrote: > > 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. In the case of two MI channels, and assuming the issue with MI events not currently being broadcast to all channels/UIs is fixed, then such a -break-insert would show up as event in the other MI channel, and that other channel would have no way to know that that breakpoint is supposed to be internal. It would seem like this suggests that for such a use case, the breakpoint itself should carry some "this is an internal breakpoint" property. Note you can create internal breakpoints with Python today, but not with MI. Thanks, Pedro Alves