From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10586 invoked by alias); 30 May 2006 21:30:43 -0000 Received: (qmail 10570 invoked by uid 22791); 30 May 2006 21:30:42 -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; Tue, 30 May 2006 21:30:40 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-87.snap.net.nz [202.124.112.87]) by viper.snap.net.nz (Postfix) with ESMTP id F3DBD7583D4; Wed, 31 May 2006 09:30:38 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 468041D3550; Wed, 31 May 2006 09:30:01 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17532.47448.102689.556136@kahikatea.snap.net.nz> Date: Wed, 31 May 2006 10:29:00 -0000 To: Bob Rossi Cc: gdb@sources.redhat.com Subject: Re: MI query questions In-Reply-To: <20060530171437.GA31100@brasko.net> References: <20060529122337.GB2021@brasko.net> <17531.47715.244586.380765@kahikatea.snap.net.nz> <20060530171437.GA31100@brasko.net> X-Mailer: VM 7.19 under Emacs 22.0.50.18 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-05/txt/msg00408.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: (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. -- Nick http://www.inet.net.nz/~nickrob