From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11806 invoked by alias); 9 Aug 2005 17:07:49 -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 11485 invoked by uid 22791); 9 Aug 2005 17:07:43 -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:07:43 +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 j79H7fFk021031 for ; Tue, 9 Aug 2005 10:07:41 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 9 Aug 2005 10:07:41 -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 j79H7cee009445 for ; Tue, 9 Aug 2005 10:07:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <1123605445.30442.ezmlm@sources.redhat.com> References: <1123605445.30442.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: RFC: MI output during program execution Date: Tue, 09 Aug 2005 17:24:00 -0000 To: gdb-patches@sources.redhat.com X-SW-Source: 2005-08/txt/msg00097.txt.bz2 Eli, You don't want to run ALL cli commands through the mi command equivalents because then the output would come out in mi form, not cli form. You really want to try to maintain the fidelity of the original CLI command even when running them under the MI, or the user's experience with the console will be disconcerting. I think that's why Nick only grabbed the ones he wants to get information from. 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. This is pretty easy to do - at least with hooks it is, I haven't converted our code over to observers - and means you don't need to go command by command, which would be a PITA indeed, and as I said would lose with user-defined commands in any case... Jim On Aug 9, 2005, at 9:37 AM, gdb-patches-digest- help@sources.redhat.com wrote: > I'm a bit nervous about this literal testing of certain commands: why > not allow _any_ CLI commands to be supported in this way? I > understand that you were trying to mention every command that runs the > inferior, but the implication is that we will need to remember to add > to this list any new command that has similar effects. That sounds > like a PITA; could a more general solution be devised? > > But I'm afraid that I'm somehow missing something, so could you please > elaborate on the design of the solution you propose? > > >