From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28260 invoked by alias); 7 Feb 2009 01:04:26 -0000 Received: (qmail 28251 invoked by uid 22791); 7 Feb 2009 01:04:25 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 07 Feb 2009 01:04:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9AF602A96E0; Fri, 6 Feb 2009 20:04:18 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zIyjo-9cGltp; Fri, 6 Feb 2009 20:04:18 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id EB59A2A96D8; Fri, 6 Feb 2009 20:04:17 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 20BF2E7ACD; Fri, 6 Feb 2009 17:04:15 -0800 (PST) Date: Sat, 07 Feb 2009 01:04:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Vladimir Prus , gdb-patches@sources.redhat.com, Nick Roberts , Marc Khouzam Subject: Re: [RFA] fix *stopped for CLI commands Message-ID: <20090207010415.GF3676@adacore.com> References: <200902061045.18508.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00169.txt.bz2 > Vladimir> This patch fixes this by making MI observer print frame > Vladimir> again, into MI uiout, if necessary. It passes all MI tests > Vladimir> in (sync,async)x(native,gdbserver) combinations. How does > Vladimir> this look, and are non-MI changes OK? If approved, I'll add > Vladimir> a test that CLI commands result in proper *stopped. > > I don't understand all the implications of the core change, but I do > like how it moves some MI logic out of the core and into MI. Agreed. Ideally, I'd really like to see all such notifications be handled by observers, even the CLI ones. -- Joel