From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6874 invoked by alias); 13 Jul 2006 22:45:17 -0000 Received: (qmail 6863 invoked by uid 22791); 13 Jul 2006 22:45:16 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Jul 2006 22:45:13 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-55.snap.net.nz [202.124.112.55]) by viper.snap.net.nz (Postfix) with ESMTP id DA12D773D8A; Fri, 14 Jul 2006 10:45:08 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 4E14B1D3550; Fri, 14 Jul 2006 10:43:53 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17590.52391.979539.124310@kahikatea.snap.net.nz> Date: Thu, 13 Jul 2006 22:45:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb@sources.redhat.com, Jim Ingham Subject: Re: mi_load_progress question In-Reply-To: <20060713130319.GA21874@nevyn.them.org> References: <200607121239.07906.vladimir@codesourcery.com> <17588.49586.825386.426144@kahikatea.snap.net.nz> <20060712140431.GA18249@nevyn.them.org> <20060713064616.BE4E11D3550@kahikatea.snap.net.nz> <20060713130319.GA21874@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.37 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/msg00076.txt.bz2 > > I have no experience with remote debugging, so I can only suggest that > > it's consistent i.e have progress reporting for all cases or turn it off > > completely (I don't know how useful it is or why it should only exist in > > MI). > > There's similar output from the CLI including speed and section name. The progress reporting is described for -target-download but not mentioned for load. > > If the answer is yes, I suggest something like the patch below. Unless I'm > > missing something mi_load_progress only gets called in MI. I would like to > > make similar but more fiddly changes to mi-interp.c, removing > > mi`N'_command_loop, N = 1,2,3, and just using mi_command_loop. > > You're wrong; take a look at the URL from my message. If you > type "load" at the MI prompt, the hook remains installed, but we get > called while the CLI is temporarily active. Doing this will probably > crash. OK. I can see a problem now: if I start GDB normally and use a command like "interpreter mi -environment-pwd". Otherwise deprecated_show_load_progress is presumably only set to mi_load_progress if GDB is invoked with "-i=mi[N]" as there is currently there is no ability to switch interpreters permanently in FSF GDB. Or is the problem more general than that? When I read the thread I thought it was referring to executing CLI commands from MI, in which case you presumably would want the MI output. Perhaps mi_load_progress could just do: if (mi_version (uiout) != 0) uiout = mi_out_new (mi_version (uiout)); else return; > You can test this using gdbserver; "load" isn't useful with gdbserver, > but if you load the same binary gdbserver started, it works well enough > to test "load". I don't see how mi_load_progress would run in this case. -- Nick http://www.inet.net.nz/~nickrob