From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5173 invoked by alias); 1 Jun 2006 00:58:40 -0000 Received: (qmail 5163 invoked by uid 22791); 1 Jun 2006 00:58:39 -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, 01 Jun 2006 00:58:36 +0000 Received: from kahikatea.snap.net.nz (p275-tnt1.snap.net.nz [202.124.111.21]) by viper.snap.net.nz (Postfix) with ESMTP id E3AAD75818B; Thu, 1 Jun 2006 12:58:34 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id DD2051D3550; Thu, 1 Jun 2006 12:57:55 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17534.15249.56900.580577@kahikatea.snap.net.nz> Date: Thu, 01 Jun 2006 00:58:00 -0000 To: Bob Rossi Cc: gdb@sources.redhat.com Subject: Re: MI query questions In-Reply-To: <20060531102856.GA29425@brasko.net> References: <20060529122337.GB2021@brasko.net> <17531.47715.244586.380765@kahikatea.snap.net.nz> <20060530171437.GA31100@brasko.net> <17532.47448.102689.556136@kahikatea.snap.net.nz> <20060531102856.GA29425@brasko.net> X-Mailer: VM 7.19 under Emacs 22.0.50.19 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-06/txt/msg00000.txt.bz2 > > > > I suggest, for the moment, at least, that we make MI select "[1] all" > > > > automatically in this case. > > > > > > Nick, > > > > > > I don't think this solves the problem though. As Daniel pointed out, > > > > > > -interpreter-exec console "b A::func" > > > > > > will cause the same problem, and needs to be addressed. I haven't > > > thought this through well enough though. > > > > Well, I guess it depends whether the existing behaviour breaks the front > > end or not i.e when the prompt ">" appears will it know that GDB wants > > more input or not? If the answer is yes (I've not tried it) then things > > can be left as they are. If its no, then something should be done and the > > solution being proposed doesn't sound like a quick fix. > > > > "-interpreter-exec console "b A::func" could presumably be made to behave > > as "-break-insert A::func". Witness pending breakpoints: > > I wouldn't like to change the behavior of the CLI commands. This would > be confusing to users and I don't think they would like it at all. I don't know how it would work to keep existing CLI behaviour. I think "-interpreter-exec console" only works for single isolated CLI commands and not for ones like "source", "commands", "if", "while" etc or user-defined ones. Current behaviour seems to be broken, I'm just trying to suggest an immediate temporary fix. Will your solution be ready for 6.5? > > (gdb) > > -break-insert fgfg > > &"Function \"fgfg\" not defined.\n" > > ^done > > (gdb) > > -interpreter-exec console "b ghgh" > > &"Function \"ghgh\" not defined.\n" > > ~"Breakpoint 1 (ghgh) pending.\n" > > ^done > > (gdb) > > inf bre > > &"inf bre\n" > > ~"Num Type Disp Enb Address What\n" > > ~"1 breakpoint keep y ghgh\n" > > ^done > > (gdb) > > > > For the CLI command "break" the behaviour seems to be reversed but it's > > no longer a query. > > I think this is a bug in GDB that there is no longer a query. The user > is going to want to know why they are not prompted when using the FE, > but they are prompted when using GDB. I think this is a step backwards, > not forwards. We've had this one before. With "b ghgh", deprecated_query_hook has the value mi_interp_query_hook which always returns 1, so this is deliberate. With "-break-insert fgfg" the error `Function "fgfg" not defined.' is caught further up the stack and GDB never gets a chance to set the breakpoint. I don't know if that's deliberate. -- Nick http://www.inet.net.nz/~nickrob