From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18479 invoked by alias); 4 Jan 2012 03:52:10 -0000 Received: (qmail 18467 invoked by uid 22791); 4 Jan 2012 03:52:08 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 03:51:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8C6E42BAF5D; Tue, 3 Jan 2012 22:51:45 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WmFXn7266FQP; Tue, 3 Jan 2012 22:51:45 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 173CE2BAF5B; Tue, 3 Jan 2012 22:51:44 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8336C145615; Wed, 4 Jan 2012 07:51:28 +0400 (RET) Date: Wed, 04 Jan 2012 03:52:00 -0000 From: Joel Brobecker To: Marc Khouzam Cc: "'gdb@sourceware.org'" Subject: Re: Pending breakpoints on lines that don't exist Message-ID: <20120104035128.GP2742@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00001.txt.bz2 > one, which attempts to set a breakpoint on an invalid line. > GDB 7.4 now sets a pending breakpoint on lines that don't > exist. Is this a regression or a wanted change? > I didn't want to update my tests if this was a regression. I am not the author of the change, but I did participate a bit in its evaluation, so think of my reply as a DNS sending a "non-authoritative" answer :-). I think that the idea is that another objfile, typically a shared library, might appear later on. If that shared library has a file where this line number is valid, we want the breakpoint to include this location. Does that make sense? I can imagine that it is a bit of a pain to see pending breakpoints being created for human-entry errors. I tend to make this type of error regularly, for instance. But it apparently it is only an issue if you use the "console" interpreter, since "-break-insert" flat out refuses the breakpoint for me: (gdb) -break-insert foo.c:100 ^error,msg="No line 100 in file \"foo.c\"." ... whereas "break" asks me whether I want to insert a breakpoint: (gdb) b foo.c:100 No line 100 in file "foo.c". Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b bar.c:100 No source file named bar.c. Make breakpoint pending on future shared library load? (y or [n]) n In any case, I do not think it's going to be a problem for graphical front-end users, where I imagine most breakpoints are inserted by clicking on a specific line of source code (with the exception of the binary being out of sync with the sources). And I don't think it's going to be a problem for the console users, because the error message seems clear enough to not leave the user in the dark. -- Joel