From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27914 invoked by alias); 15 Mar 2006 16:39:34 -0000 Received: (qmail 27906 invoked by uid 22791); 15 Mar 2006 16:39:33 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao06.cox.net (HELO eastrmmtao06.cox.net) (68.230.240.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Mar 2006 16:39:32 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao06.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060315163924.QIXG9108.eastrmmtao06.cox.net@localhost.localdomain>; Wed, 15 Mar 2006 11:39:24 -0500 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FJZ2Y-0008Kn-61; Wed, 15 Mar 2006 11:40:02 -0500 Date: Wed, 15 Mar 2006 16:48:00 -0000 From: Bob Rossi To: Jim Ingham Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: MI and pending breakpoints Message-ID: <20060315164002.GB30980@brasko.net> Mail-Followup-To: Jim Ingham , Vladimir Prus , gdb@sources.redhat.com References: <27491BE6-9DDB-4168-BDFC-9C092BF0DEBB@apple.com> <20060315162122.GA30980@brasko.net> <01D1CA11-FB79-43C6-AD3F-DC4C3D49B465@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01D1CA11-FB79-43C6-AD3F-DC4C3D49B465@apple.com> 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-03/txt/msg00083.txt.bz2 On Wed, Mar 15, 2006 at 08:34:55AM -0800, Jim Ingham wrote: > > On Mar 15, 2006, at 8:21 AM, Bob Rossi wrote: > > >On Wed, Mar 15, 2006 at 08:19:59AM -0800, Jim Ingham wrote: > >>You need to set the gdb variable "pending" to "on" before setting the > >>breakpoint. Since this is kind of a pain, we added a "-f" option > >>to - > >>break-insert that will do this for you wrapped around the breakpoint > >>setting ("-f" because this feature was called "future-break" in the > >>NeXT gdb many years ago.) > >> > >>It's also arguable that for -break-insert you ALWAYS want "pending" > >>to be "on". > > > >That's how annotate=2 works. However, I think GDB should query the > >user > >the same way it does from the CLI. It's wierd when people start > >using my > >front end and ask why it behaves differently than the CLI. > > Not sure I agree with this. AFAICT, the main reason for asking the > user is that you can easily mis-type a file:line spec, and it's good > to have the CLI tell you this didn't set so you can check your > spelling. But this should not be possible for the most common type > of breakpoint in a UI, which is clicking in the gutter of an editor > window. > > I think having the UI query would be disruptive... OK, I understand what you mean, and sort of agree. I assume you are talking about when the GUI issues the command for the breakpoint based on some interaction with the user. I think that the FE should be fully aware of the fact that the breakpoint will be pending. GDB should query the FE (in the MI sense) and the FE can alert the user if it chooses, or simply always set the breakpoint. This provides the most flexibility. I would only expect this query to happen if the 'set' variable for that says it should be queried. The user may want to know if it's pending or not. Also, a nice feature would be to add this to the breakpoint MI output data if it's not already there. Here is the situation I'm talking about. When the user types 'b file:line' in the console that the FE provides them, and they do not get a query back from GDB when using annotate=2. It simply always set's the breakpoint. I don't know if MI currently works the same. Bob Rossi