From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27989 invoked by alias); 9 Feb 2005 02:33:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27910 invoked from network); 9 Feb 2005 02:33:08 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 9 Feb 2005 02:33:08 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050209023308.YGOH29855.lakermmtao08.cox.net@white>; Tue, 8 Feb 2005 21:33:08 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CyhfA-0006Y1-00; Tue, 08 Feb 2005 21:33:08 -0500 Date: Wed, 09 Feb 2005 04:51:00 -0000 From: Bob Rossi To: Andrew Cagney , g@white Cc: gdb@sources.redhat.com Subject: Re: MI output change Message-ID: <20050209023308.GA24849@white> Mail-Followup-To: Andrew Cagney , g@white, gdb@sources.redhat.com References: <41E8316F.7050806@gnu.org> <4208E71A.5070307@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4208E71A.5070307@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-02/txt/msg00053.txt.bz2 On Tue, Feb 08, 2005 at 11:21:46AM -0500, Andrew Cagney wrote: > Andrew Cagney wrote: > Two ya's, no Na's. All but 'done' :-/ > >Hello, Has this patch been committed yet? The last failing MI testcase I have in the syntax checked MI testsuite is one related to this problem. If you've committed the change for this, I still have an example that behaves as below. Bob Rossi > >The MI output is currently littered with: > > > >(gdb) > >PASS: gdb.mi/mi-var-cmd.exp: create lsimple->integer > >-var-create int * int > >&"Attempt to use a type name as an expression.\n" > >&"mi_cmd_var_create: unable to create variable object\n" > >^error,msg="mi_cmd_var_create: unable to create variable object" > >(gdb) > > > >(note how the error appears as both the result and as standard out) > > > >My recent exception handling rewrite means that this can finally be > >fixed. However that means that the MI output has technically changed - > >no one should be relying on the message appearing on stdout but hey ... > > > >Is this going to be an issue? > > > >Andrew > >