From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27028 invoked by alias); 12 Aug 2005 16:43:17 -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 26871 invoked by uid 22791); 12 Aug 2005 16:43:11 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 12 Aug 2005 16:43:11 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j7CGh9no025539 for ; Fri, 12 Aug 2005 09:43:09 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 12 Aug 2005 09:43:08 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j7CGh6pk024155; Fri, 12 Aug 2005 09:43:06 -0700 (PDT) In-Reply-To: <20050812012810.GA10011@white> References: <1123605445.30442.ezmlm@sources.redhat.com> <20050809181311.GB3012@white> <20050809223421.GB3557@white> <20050810004128.GA4264@nevyn.them.org> <20050810004826.GD3557@white> <2040BEEA-4200-4118-91EB-D093ED4D37A1@apple.com> <20050812012810.GA10011@white> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29EA180F-E3C7-4D04-B500-655391EDA2D9@apple.com> Cc: Eli Zaretskii Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFC: MI output during program execution Date: Fri, 12 Aug 2005 17:03:00 -0000 To: Bob Rossi , gdb-patches@sources.redhat.com X-SW-Source: 2005-08/txt/msg00134.txt.bz2 On Aug 11, 2005, at 6:28 PM, Bob Rossi wrote: >> Remember I haven't done this with observers or events yet. The way I >> did it with hooks, the result of the hooks is gathered into the >> "^done" or the other termination states for the command. So for >> instance, if you run gdb on itself, and do: >> > > Hi Jim, > > Thanks for all the guidence so far. Even though you have not attempted > the observer approach, how do you feel about it? Is this something > that > you think could be accomplished with the current FSF GDB? Nick, Daniel > and Eli, do you like this approach? I'm sure I could find some time to > get something going in this direction, with a little bit of thought. This should work fine. Actually, the "events" that Keith introduced seems easier to do, since it looks like there's already an event call wherever there is a "deprecated_*_hook" but I am not sure what the difference between events & observers is supposed to be... > > Anyone else willing to work towards this solution? > > I really like Daniel's idea of just alerting the user that > something has > changed, instead of actually giving the user the data. For instance he > had, > > =breakpoint-changed,[bpnum="1",state="disabled"] > =thread-changed,[thread="2"] > > I might even prefer, > =breakpoint-changed,thread-changed > which would then allow the FE to call -list-breakpoints or whatever if > they are interested. Why? These sorts of events are never going to have that much data in them. Why would you want to force another round trip just to avoid packaging up some data that you already have on hand. That just makes the UI's job more complicated. For instance, if a breakpoint command set a breakpoint and started the target going again, currently you are going to have to stop the target to get the breakpoint list, which seems silly. And even if we made "-break- info" a command that you can issue while the target is going, what if it stopped again between you sending the break info and it getting processed. You will get another async message before you get the break info response... Of course the UI has got to be robust against this sort of thing, but I see no reason to make the job arbitrarily complex. Again, what is your reason for wanting to do this? Jim > > This is very similar to how annotate=2 solved the problem for when > breakpoints changed. The only wierd issue that happened with this > approach is that the data breakpoint-changed was literally outputted > thousands and thousands of times in certain circumstances. (compiled > program with optimizations). > > Thanks, > Bob Rossi >