From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101540 invoked by alias); 18 Jun 2019 20:38:37 -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 101532 invoked by uid 89); 18 Jun 2019 20:38:37 -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=notified, experienced 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; Tue, 18 Jun 2019 20:38:34 +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 x5IKcM4f021398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Jun 2019 22:38:23 +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 x5IKcKwq018270 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 18 Jun 2019 22:38:21 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <70be86e627f6ec578217f01df9af914080b181c2.camel@fit.cvut.cz> 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: Tue, 18 Jun 2019 20:38:00 -0000 In-Reply-To: <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca> References: <70fdd9107d9bb3cee0a1a342aedc05bf3c8e9bae.camel@fit.cvut.cz> <7530cc91-5457-0a84-57a4-5b64ddb95f13@simark.ca> 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/msg00052.txt.bz2 Hi, > I am skeptical about the complex logic you are talking about to handle both > =breakpoint-created notifications and responses to the -break-insert. Both contain pretty > much the same information. So rather than adding an option in GDB for emitting async > notifications unconditionally, can't you just process both using the same function? That > doesn't really complicated, but maybe I am misunderstanding your problemi, in which case > please expand. OK, let me expand (hopefully not too much) I have a (general purpose) library that provides higher-level interface to GDB/MI. Strictly speaking, it is not bound to any particular UI frontend. This library essentially provides three things: (i) (supposedly) easy to use API to send MI commands, like: gdb send: (GDBMI_break_insert arguments: { 'main' }) andWithResultDo:[ :result | result isSuccess ifTrue:[ Stdout print: 'Breakpoint inserted' ] ifFalse:[ Stderr print: 'Oops, something went wrong!' ] ] (sorry for bit arcane syntax, hope you can make sense of it) (ii) provide object model of the debugger and its state (like, inferiors, their threads, frames in thread, variables, registers, breakpoints) like: "/ Prints the stack of first thread" gdb selectedInferior threads first stack do:[:frame| Stdout print: frame printString ] The idea is that if the inferior is stopped, the model is up-to-date, when it's running, then "reasonable up-to-date", no guarantees. (iii) provide a way to get notified of changes, like: gdb when: GDBBreakpointModifiedEvent do: [:event | "/ something has changed, redraw the list to display "/ up-to-date information breakpointListPane redraw. ] This is essential to build an UI on top of this library All the above is API exposed to library user. This design has the advantages of being flexible - users can issue commands on their own, I do not have to implement and maintain wrapping API rich enough to handle all cases - and and because is close to GDB/MI, I don't really need to document it in depth, looking to GDB documentation gives you very good idea what how to use it. Reusing GDB events to notify clients of my library has the same advantage - no need to implement my own event hierarchy and document them. But if I don't get events in cases when they're result of an MI command, the only way I can think of handling it is to intercept command result event and: 1) examine the result (and sometimes the originating command itself) and do the processing 2) synthesize an event as if it were send by gdb and push it back so it's delivered to users of the library - but in this case I have to make sure it is delivered only to "external" observers and not "internal" observers which are responsible of keeping the model up-to-date. Both steps have to cared for case-by-case (like, -break-insert response carries data - the breakpoint inserted - while response to -gdb-set is plain ^done so in order to update model I have to dig into the command itself, retrieve it's parameters and reconstruct data from there). All this is indeed doable and in fact, I do this already for some commands to meet my need back then, but then I realized I need more of this and was thinking how to avoid all that code. A quick experiment shows that always emitting a notification solves most (all?) issues I experienced, which is why brought it here. Does it make sense? > > It would be useful to have a very concrete use case where you could point out "see here, > I am missing some info and a notification would be useful". It could very well be that > some notifications are just missing. To make me clear, I'm not saying that some information is missing, just that the way it is delivered seem to be inconvenient given the way I use it. It may well be I use it the wrong way :-) > For example I would argue we are missing notifications > if using two MI clients (through the new-ui command, although I don't remember if that's > "officially" supported). If one of the MI client inserts a breakpoint with -break-insert, > the other one is not notified. I would consider that a bug that the second client doesn't > get a =breakpoint-created. Yeah, having a second MI channel is a different story, I'm not considering this for now. > > 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. Thanks! Jan