From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10053 invoked by alias); 9 Aug 2005 17:59:37 -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 9866 invoked by uid 22791); 9 Aug 2005 17:59:31 -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 17:59:31 +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 j79HxTTf009343 for ; Tue, 9 Aug 2005 10:59:29 -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 10:59:28 -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 j79HxQW8005488; Tue, 9 Aug 2005 10:59:27 -0700 (PDT) In-Reply-To: <20050809175159.GA3012@white> References: <1123605445.30442.ezmlm@sources.redhat.com> <20050809175159.GA3012@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:09:00 -0000 To: Bob Rossi X-SW-Source: 2005-08/txt/msg00101.txt.bz2 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. Jim On Aug 9, 2005, at 10:51 AM, Bob Rossi wrote: >> But as I said in my previous note, I think a better solution is to >> use hooks/observers/events or whatever to allow the MI to be informed >> about things it needs to know about "behind the back" of the CLI >> that's running the command. >> > > Could you please give a quick example of something "the FE needs to > know > about?" Would there be a default way to get all the things the FE > cares about? Is it as easy as making a new MI command > -mi-get-state > which would output a list of items the FE cares about? > > Thanks, > Bob Rossi >