From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31597 invoked by alias); 18 Nov 2005 15:54:30 -0000 Received: (qmail 31588 invoked by uid 22791); 18 Nov 2005 15:54:28 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Nov 2005 15:54:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Ed8ZG-0002fB-5y; Fri, 18 Nov 2005 10:54:26 -0500 Date: Fri, 18 Nov 2005 17:12:00 -0000 From: Daniel Jacobowitz To: Andrew STUBBS Cc: gdb-patches@sources.redhat.com Subject: Re: MI problem Message-ID: <20051118155426.GB9846@nevyn.them.org> Mail-Followup-To: Andrew STUBBS , gdb-patches@sources.redhat.com References: <4378DDB4.3020702@st.com> <20051117042008.GE3513@nevyn.them.org> <437CD72D.70104@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437CD72D.70104@st.com> User-Agent: Mutt/1.5.8i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00334.txt.bz2 Any MI folks listening? On Thu, Nov 17, 2005 at 07:17:01PM +0000, Andrew STUBBS wrote: > mi_load_progress is actually called through the function pointer > deprecated_show_load_progress. > > The problem appears to be that the program is finding it's way into the > MI through deprecated_show_load_progress when uiout is not set as expected. Yes, this is the problem. > The problem only occurs in -i=mi (no number) and -i=mi1 because > mi_load_progress does not do anything in other versions. Strangely -i=mi > is supposed to be the same as -i=mi2, but it isn't in this respect. It looks like this is a mistake. I believe that when that check was added, there were only MI and MI1. When the version was bumped, it was left behind. So should we fix it, or leave it disabled? On a related note I would have expected current_interp_named_p to return false while executing a program in the CLI interpreter. interpreter_exec_cmd always sets the current interpreter. But that is only the CLI implementation of interpreter-exec. The MI implementation doesn't do this. I'm always confused in the twisty maze of interpreters. I think we can't ditch this broken behavior until we're done with "the CLI hack" (CLI commands printing out MI format output because there is no equivalent MI command). That'd be a good project for someone. > I attach a patch which fixes both the crash and the inconsistency. I > have tested it and got no unexpected failures. Of course I doubt the > testsuite covers this feature ... > > OK? I would like to see this issued fixed in 6.4 also. > > Andrew Stubbs > 2005-11-17 Andrew Stubbs > > * mi/mi-main.c (mi_load_progress): Don't do anything for -i=mi. > Ensure the use of mi1 uiout for the duration of the function. How about we commit this without the current_interp_named_p change for now? Normally we'd need to use a cleanup to save and restore uiout, but nothing here can throw exceptions AFAICT, so we're OK with the way you've done it. -- Daniel Jacobowitz CodeSourcery, LLC