From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4451 invoked by alias); 12 Jul 2006 14:04:39 -0000 Received: (qmail 4443 invoked by uid 22791); 12 Jul 2006 14:04:39 -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.1) with ESMTP; Wed, 12 Jul 2006 14:04:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G0fKK-0004pi-Hn; Wed, 12 Jul 2006 10:04:32 -0400 Date: Wed, 12 Jul 2006 14:04:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb@sources.redhat.com, Jim Ingham Subject: Re: mi_load_progress question Message-ID: <20060712140431.GA18249@nevyn.them.org> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb@sources.redhat.com, Jim Ingham References: <200607121239.07906.vladimir@codesourcery.com> <17588.49586.825386.426144@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17588.49586.825386.426144@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00045.txt.bz2 On Wed, Jul 12, 2006 at 09:32:34PM +1200, Nick Roberts wrote: > Vladimir Prus writes: > > > > Hi, > > I see some strange logic in the mi_load_progress function (file mi/mi-main.c). > > That function is responsible for printing progress report when downloading > > program to target, and the code in question is: > > > > if (current_interp_named_p (INTERP_MI)) > > uiout = mi_out_new (2); > > else if (current_interp_named_p (INTERP_MI1)) > > uiout = mi_out_new (1); > > else > > return; > > > > When I run gdb with "--i=mi2", this code exists with "return", producing to > > progress information. Is this desired behaviour? I am pretty sure that there was a bug report about this before, but I can't find it now. Ah, here: http://sourceware.org/ml/gdb-patches/2005-11/msg00295.html No one else commented at the time and I opted to stick with what we already had. Do you think we should just turn the progress reporting back on for -i=mi2? How about you, Nick? > Looking through the change history, other values didn't exist when the original > code was written. So I guess it's not desired behaviour. > > if (current_interp_named_p (INTERP_MI1)) > uiout = mi_out_new (1); > else if (current_interp_named_p (INTERP_MI) > || current_interp_named_p (INTERP_MI2)) > uiout = mi_out_new (2); > else if (current_interp_named_p (INTERP_MI3)) > uiout = mi_out_new (3); > else > return; > > would work (until new MI levels are introduced!). It would be best to generalise > this and similar code to make it future proof. Or come up with some other way to do this that avoids the need for the hack. The problem was that we were calling the MI load progress hook through the wrong interpreter. We need to figure out how to do this right. First question: Should typing "load" at the MI prompt issue +download updates? Currently it does. It also issues the CLI's updates. Second question: Should typing "-interpreter-exec console load" issue +download updates? Currently it does the same as "load" and that's the right thing to do so this is the same as the first question. Jim, maybe you've got an opinion on this? Apple seems to make more use of the CLI support than anyone else :-) -- Daniel Jacobowitz CodeSourcery