From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17756 invoked by alias); 19 Jun 2019 20:58:06 -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 17545 invoked by uid 89); 19 Jun 2019 20:58:05 -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=decades, H*i:sk:d56154b, people's, peoples 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; Wed, 19 Jun 2019 20:58:03 +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 x5JKvl2x057317 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jun 2019 22:57:49 +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 x5JKvgGW091165 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 19 Jun 2019 22:57:43 +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: Wed, 19 Jun 2019 20:58:00 -0000 In-Reply-To: References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca> <70be86e627f6ec578217f01df9af914080b181c2.camel@fit.cvut.cz> 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/msg00060.txt.bz2 Hi, On Wed, 2019-06-19 at 11:29 -0400, Simon Marchi wrote: > > > Hi Jan, > > Thanks for the detailed explanation. > > I am not in your shoes, so I might have a wrong picture of the situation, but this doesn't > sound really complicated. Isn't "synthesizing" an event from the command result just calling > the same function as you do when getting a =breakpoint-created. Or am I missing something? In case of -break-insert is not that much of work since command response carries the breakpoint object and event also arries just the breakpoint objects. But consider `set` CLI and `-gdb-set` MI commands: (gdb) set directories /foo/bar &"set directories /foo/bar\n" &"Warning: /foo/bar: No such file or directory.\n" =cmd-param-changed,param="directories",value="/foo/bar:$cdir:$cwd" ^done (gdb) and -gdb-set directories /baz/qux &"Warning: /baz/qux: No such file or directory.\n" ^done In this case. the response carries no data at all so in order to synthesize the event I need to look at the originating command and parse its arguments to pick the name and value. And as you can see above, the value parameter to the command is just "/foo/bar" while the value in the event is "/foo/bar:$cdir:$cwd" - another little thing to care about in this very case. Indeed, not a rocket science, but as you see, it requires to write a little specialized piece of code for "every" command (vs. not having to write anything at all if I'd get the event from GDB). Maybe the phrase "complex logic" was improper - complex in a way that each case has to be dealt with individually and if one forgets, the internal model can get out of sync. > > I don't really understand the difference between external and internal observers (that's > probably specific to your design). Specifically, I don't see what's the difference between > a "real" event that would come from GDB, versus an synthetic event that you would have > injected in your system from the -break-insert response. > > Let's say you do get async events for breakpoints you create with -break-insert, then you would > forward these events to all these observers? So in the case where you generate these events > yourself based on the -break-insert response, why shouldn't you also send them to all observers? Yeah, this is specific to my design. It is just that the library itself registers observers on events in order to update the model of debugger (using the same mechanic, same patterns) so when it is "synthetic" event, is has to be processed slightly differently. Not sure if it makes much sense to go to such details. > The observers wouldn't know whether it's a "real" event coming from GDB or one you created > yourself, so it shouldn't make any difference to them. > > Or (re-reading your message, I realized that this is what you might be trying to explain) > are you saying that your library is very low level, and that users of the library send > "-break-insert" on their own and your library just forwards the MI command to GDB, so your > library doesn't really know (unless it sniffs the user command) that a -break-insert > command has been issued? Precisely! The library does not really know and therefore would have to "sniff". > If so, that might explain my incomprehension. All the MI-handling > code I have been exposed to has been a bit more high level, where the user calls some > "breakInsert" function of the library. The library knows it's sending a -break-insert, so > it can easily handle the response however it wants (including generating a "breakpoint created" > event if it wants to). Yeah, I guess that's more common approach. I decided to make it more lower-level as this gives me more flexibility. Or so it looked back then :-) > > > Also, I am a bit worried by a proposal in the thread, which would be to remove information > > > from the -break-insert ^done response, arguing that the async notification would have already > > > been emitted. It is clear and unambiguous how to map a response to a request, but it would not > > > be obvious to map an async notification to a request. So it appears to me as a regression in > > > functionality. > > > > This is why I said that - for example - for -break-insert we need to respond with - at least - > > ^done,bkpt-number=1. For some other. like -gdb-set I don't think we need to > > What I am worried about is that doing a change like this has a pretty big cost for on all frontends > that have this currently implemented, so it needs to have a pretty strong justification. It's not just > moving the data fields a little bit, or adding something that everybody else can ignore, it would require > a significant flow change. A frontend that is just interested in setting a breakpoint and getting the > result of that (i.e. the simple case) now needs to do something non-trivial: send the command, listen for > an event, store it somewhere, handle it when receiving the ^done corresponding to the command. This > brings some concurrency/race condition problems that are just not there in the request-response scheme. Yes, I completely understand. This and this is a valid concern. I said it before - the last thing I want is to break other people's stuff "that works for decades" because of my obscure thing. If the decision out of this discussion is "no", I'll happily deal with it in my library. No problem whatsoever. > > So at least, if we end up choosing to unconditionally emit the =breakpoint-created event, I would prefer > keeping the -break-insert response as-is, for backwards compatibility (for existing frontends) and > simplicity (for basic use cases), even if it means there's some redundancy. > Yes, that was my original proposal, keep everything as it is, just to emit events in addition. Either unconditionally or only if mi-always-async is set (at the cost of having yet another option which is also far from ideal). Jan