From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26483 invoked by alias); 13 Aug 2005 00:33: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 26464 invoked by uid 22791); 13 Aug 2005 00:33: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; Sat, 13 Aug 2005 00:33:11 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j7D0X9CQ006296 for ; Fri, 12 Aug 2005 17:33:09 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 12 Aug 2005 17:33:08 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id j7D0X6kX011811; Fri, 12 Aug 2005 17:33:07 -0700 (PDT) In-Reply-To: <20050813002230.GA11892@white> References: <20050809181311.GB3012@white> <20050809223421.GB3557@white> <20050810004128.GA4264@nevyn.them.org> <20050810004826.GD3557@white> <2040BEEA-4200-4118-91EB-D093ED4D37A1@apple.com> <20050812012810.GA10011@white> <29EA180F-E3C7-4D04-B500-655391EDA2D9@apple.com> <20050813002230.GA11892@white> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: gdb-patches@sources.redhat.com, Eli Zaretskii Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFC: MI output during program execution Date: Sat, 13 Aug 2005 00:44:00 -0000 To: Bob Rossi X-SW-Source: 2005-08/txt/msg00147.txt.bz2 Bob, On Aug 12, 2005, at 5:22 PM, Bob Rossi wrote: >>> 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... >> > > OK, unfortunatly, I'm still trying to catch up here. I think I > understand the observer approach, however, what is the event approach? > Is that different than the "hooks" you have? I don't have a good answer here, there is some history that I don't fully understand. There used to be _hook functions, that you put in various interesting places in gdb, and called like: if (create_breakpoint_hook) create_breakpoint_hook (b); So in the MI, when I am about to call into the cli interpreter, first I put in place a bunch of hooks, and then they get called to tell me if anything interesting happens. In current TOT gdb, I see instead: if (deprecated_create_breakpoint_hook) deprecated_create_breakpoint_hook (b); breakpoint_create_event (b->number); where breakpoint_create_event does: void breakpoint_create_event (int b) { if (gdb_events_debug) fprintf_unfiltered (gdb_stdlog, "breakpoint_create_event\n"); if (!current_event_hooks->breakpoint_create) return; current_event_hooks->breakpoint_create (b); } Okay... So it LOOKS like the "events" are supposed to be the replacements for the hooks... But then there's the whole observer thing, which from what I read of the gdb-patches traffic at the time was supposed to be a more general solution for watching interesting events. But it doesn't seem to be used all that much. So I am not really sure what's supposed to be happening here. Moving from hooks to events seems a trivial formal exercise. I don't know if they will get deprecated soon or what, however... > > >>> 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? >> > > Well, I just figured it would be easier to say, "This has changed", > instead of giving the entire change. However, if I'm wrong here, > that is > fine. It's easy to change this kind of thing once the functionality is > in place. As long as the approach is aggreed on, then I think we'll > all > be happy. Cool... Jim