From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21285 invoked by alias); 1 Oct 2002 23:39:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21278 invoked from network); 1 Oct 2002 23:39:55 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 1 Oct 2002 23:39:55 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g91NL9i31403 for ; Tue, 1 Oct 2002 19:21:09 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g91Ndsf16715; Tue, 1 Oct 2002 19:39:54 -0400 Received: from valrhona.uglyboxes.com (IDENT:GsM84MINzHEdhFHGMNnf3H95DW+emCnJ@vpn50-27.rdu.redhat.com [172.16.50.27]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g91NdqK00491; Tue, 1 Oct 2002 19:39:52 -0400 Date: Tue, 01 Oct 2002 16:39:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Jim Ingham cc: Andrew Cagney , Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 In-Reply-To: <70563052-D58F-11D6-BB61-00039379E320@apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-10/txt/msg00026.txt.bz2 On Tue, 1 Oct 2002, Jim Ingham wrote: > BTW, I haven't seen the actual change Keith is planning here. Will he > be sticking the command sequence cookie in the async result? His > example didn't show the cookies. For the record, the proposed change would look like: (gdb) 200-break-insert main =breakpoint-create,number="1" 200^done (gdb) > Seems to me that reporting command results as an async notification > means that we are breaking the tie between the command and its results. And is that necessarily bad? (More on my confusion below...) > It was very nice that I could issue a bunch of commands at some point > in the GUI code, then at another place gather up the results, and match > them to the initial commands by using the sequence ID's. I'm afraid that I'm not following. Could you please expound? Why would you want a tight coupling of commands and their results? What's wrong with just issuing a command at GDB and waiting for GDB to tell you that it's done something? It seems to me that the less serialization that a UI does, the more time it has to spend in its event loop and the more responsive it will feel to the user (barring the java way: create a freakin' thread for everything). > In the new way of doing things, we have to parse more carefully, and > assume that the =breakpoint-create that we just got was the one that > came from the -break-insert in the output just above it. It makes the > client stream parser have to be more stateful that in the mi0 version, > which doesn't seem to me all that good an idea. If the async event has > the cookie in it, this will be a little better, though it still means I > have a two-step accumulation phase for each command (wait for the async > result with the right cookie, then the done with the right cookie...) Ditto the above. Maybe -break-insert and =breakpoint-create are bad examples(?), but I am not able to imagine why it would matter which command elicited the notification. Commands are issued, and something happens. The only case I can imagine where this is important is when an error occurs setting the breakpoint, but MI will (and will continue) to report errors immediately. Maybe something related to async targets? (BTW, there is no reason why I/we cannot/could not put the old behavior back for an MI0 target, if 'mi0' were sticking around, which is a decision I want nothing to do with, actually.) One is still pretty screwed, though, when "interpreter-exec" is used, unless we revert from async notification back to serial notification via hook hack that you're using. As far as the versioning thing goes, I must say that I don't really care, (not that my opinion matters), but I can understand why some on this list would be less sympathetic with objections to dropping mi0 coming from Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of stuff, but only managed to "submit" a giant distribution tarball of their modified GDB. I wouldn't be too suprised if some thought that Apple was taking advantage of the public's work. Mind you, I'm not saying that any of this is true, but I wouldn't be suprised if some one reading this list felt that way. Keith