From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7185 invoked by alias); 9 Aug 2005 18:34:51 -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 7138 invoked by uid 22791); 9 Aug 2005 18:34:40 -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; Tue, 09 Aug 2005 18:34:40 +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 j79IYb5s019887 for ; Tue, 9 Aug 2005 11:34:37 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Tue, 9 Aug 2005 11:34:37 -0700 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id j79IYZZG023737; Tue, 9 Aug 2005 11:34:35 -0700 (PDT) In-Reply-To: <20050809182320.GC3012@white> References: <1123605445.30442.ezmlm@sources.redhat.com> <20050809175159.GA3012@white> <20050809182320.GC3012@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 Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFC: MI output during program execution Date: Tue, 09 Aug 2005 18:40:00 -0000 To: Bob Rossi X-SW-Source: 2005-08/txt/msg00106.txt.bz2 On Aug 9, 2005, at 11:23 AM, Bob Rossi wrote: > On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote: > >> The front end needs to know if a CLI command executed via "- >> interpreter-exec console" changed the current thread or frame - so it >> can update the UI accordingly. Or if it started the target running. >> Or if it added a breakpoint. >> >> All these things could be queried from existing commands in the MI, >> but that's pretty inconvenient and inefficient. It's much easier to >> code up the UI if gdb tells it asynchronously about these things. >> > > OK, well then I completly agree that observers would be a very nice > way > to solve this problem. When an internal MI state changes, it should > alert the FE if the FE requested such knowledge. This is of course, an > asyncronous approach as far as the FE is concerned. If the FE needs > this > information now, it can simply poll GDB for this information. > > Also, I'm not convinced it would be inefficient to query GDB for the > required information, especially if a new MI command was added to GDB > that returned the current state of GDB. (frame,thread,file). "Run over all state and see what changed" is a pain compared to "tell me when something changes". If the former were hard to code up for some reason, I guess you could go for the latter, but it didn't take all that much thought to get this working... > > How does -interpreter-exec console work in the case when the user > executes a command, that makes up several other commands? > > define mess_with_mi_people > b main > r > n > n > end > > I don't think this case would currently work as expected. Would it? Remember that only one "run the target" command is allowed in a CLI define. All the others are ignored. But anyway, in our setup, the UI would get notification that a breakpoint was set, and then that the target continued. A harder one to handle is: define really_mess_with_people break function_that_gets_hit_alot commands $bpnum print someInterestingVariable continue end r end because then you are going to get the breakpoint notification, then the run notification, then the breakpoint hit, at which point the target is going to start again, etc... I don't see how you really solve this one with the UI polling for state. But with the hooks and just a little bit of judicious trickery (we added a "breakpoint commands running" and "breakpoint commands done running" events so the UI would know to hold off doing it's "breakpoint hit handling" till the commands were done) we have this one working as well. Jim > > Thanks, > Bob Rossi >