From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23880 invoked by alias); 12 Aug 2005 21:01:57 -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 23862 invoked by uid 22791); 12 Aug 2005 21:01:53 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 12 Aug 2005 21:01:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1E3gf0-0008Bf-Nq; Fri, 12 Aug 2005 17:01:50 -0400 Date: Sat, 13 Aug 2005 00:22:00 -0000 From: Daniel Jacobowitz To: Jim Ingham , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: RFC: MI output during program execution Message-ID: <20050812210150.GC30801@nevyn.them.org> Mail-Followup-To: Jim Ingham , Eli Zaretskii , gdb-patches@sources.redhat.com 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050812012810.GA10011@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-08/txt/msg00145.txt.bz2 On Thu, Aug 11, 2005 at 09:28:10PM -0400, 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. Just to clarify what I said downthread to Eli: I don't think that this requires "observers" in any sense. I think we want to do something specific to notifying interpreters, or even something specific to notifying the MI interpreter (I'm not sure which is a better idea, to be honest). So perhaps you should find something else to call it :-) > 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"] That wasn't my idea, although they were my examples - those were exactly the available information. I support providing the data, unless it becomes large or complicated. Which it may especially for breakpoints! We need an implementation to experiment with. > 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). Fortunately, this is pretty easy to handle in MI land. I suspect that we will usually only want the notification once if it's just =breakpoint-changed. Especially if we can manage the interface so that user events generate notifications but program events don't need to... The example that concerns me is loading a shared library and having it shuffle many breakpoints around. -- Daniel Jacobowitz CodeSourcery, LLC