From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31130 invoked by alias); 15 Mar 2006 16:48:25 -0000 Received: (qmail 31121 invoked by uid 22791); 15 Mar 2006 16:48:24 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Mar 2006 16:48:23 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k2FGmB5B001828; Wed, 15 Mar 2006 08:48:11 -0800 (PST) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay5.apple.com (Apple SCV relay) with ESMTP id 64EA3324002; Wed, 15 Mar 2006 08:48:11 -0800 (PST) In-Reply-To: <20060315164002.GB30980@brasko.net> References: <27491BE6-9DDB-4168-BDFC-9C092BF0DEBB@apple.com> <20060315162122.GA30980@brasko.net> <01D1CA11-FB79-43C6-AD3F-DC4C3D49B465@apple.com> <20060315164002.GB30980@brasko.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Vladimir Prus , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI and pending breakpoints Date: Wed, 15 Mar 2006 23:18:00 -0000 To: Bob Rossi 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/msg00084.txt.bz2 On Mar 15, 2006, at 8:40 AM, Bob Rossi wrote: > 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. If the breakpoint isn't successfully set, the breakpoint address is set to "". This is part of the MI -break-insert return value. So the UI can tell whether it was set or not. If the UI wanted to do anything special, it could ask the user itself about this breakpoint, and if the user didn't want it, the UI could just delete it. We haven't had any requests for this behavior, however. Xcode does have a "breakpoints" window that indicates a bunch of things about the breakpoint, including whether it has been set yet or not. That's the way we've handled this. Jim > > Bob Rossi