From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10533 invoked by alias); 31 May 2006 10:29:28 -0000 Received: (qmail 10522 invoked by uid 22791); 31 May 2006 10:29:27 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 May 2006 10:28:57 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060531102855.IVDS9931.eastrmmtao04.cox.net@localhost.localdomain>; Wed, 31 May 2006 06:28:55 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FlNwe-000553-Tw; Wed, 31 May 2006 06:28:56 -0400 Date: Wed, 31 May 2006 13:25:00 -0000 From: Bob Rossi To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: MI query questions Message-ID: <20060531102856.GA29425@brasko.net> Mail-Followup-To: Nick Roberts , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17532.47448.102689.556136@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.9i 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/msg00410.txt.bz2 On Wed, May 31, 2006 at 09:30:00AM +1200, Nick Roberts wrote: > > > 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. > (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. Bob Rossi