From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8584 invoked by alias); 30 May 2006 17:14:45 -0000 Received: (qmail 8575 invoked by uid 22791); 30 May 2006 17:14:45 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 May 2006 17:14:41 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060530171437.IRTL15797.eastrmmtao03.cox.net@localhost.localdomain>; Tue, 30 May 2006 13:14:37 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fl7nh-00053V-PN; Tue, 30 May 2006 13:14:37 -0400 Date: Tue, 30 May 2006 17:32:00 -0000 From: Bob Rossi To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: MI query questions Message-ID: <20060530171437.GA31100@brasko.net> Mail-Followup-To: Nick Roberts , gdb@sources.redhat.com References: <20060529122337.GB2021@brasko.net> <17531.47715.244586.380765@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17531.47715.244586.380765@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/msg00390.txt.bz2 On Tue, May 30, 2006 at 03:22:11PM +1200, Nick Roberts wrote: > > This is from MI interp: > > (gdb) > > -break-insert A::func > > ~"[0] cancel\n[1] all\n" > > ~"[2] A::func(float) at overloaded.cpp:8\n" > > ~"[3] A::func(int) at overloaded.cpp:7\n" > > > > > This isn't really a query in the GDB sense of the word i.e it's not a yes/no > question and it doesn't call the function query. We've discussed queries in > MI on this mailing list before and the current behaviour is to take a default > value e.g "no" for pending breakpoints. > > 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. Bob Rossi