From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9111 invoked by alias); 4 Jan 2012 09:13:05 -0000 Received: (qmail 9093 invoked by uid 22791); 4 Jan 2012 09:13:04 -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 09:12:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 217ED2BB0D0; Wed, 4 Jan 2012 04:12:51 -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 c6-zdR5TI4PK; Wed, 4 Jan 2012 04:12:51 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 835B12BB0CA; Wed, 4 Jan 2012 04:12:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 0AE1E145615; Wed, 4 Jan 2012 13:12:40 +0400 (RET) Date: Wed, 04 Jan 2012 09:13:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: marc.khouzam@ericsson.com, gdb@sourceware.org Subject: Re: Pending breakpoints on lines that don't exist Message-ID: <20120104091240.GS2742@adacore.com> References: <20120104035128.GP2742@adacore.com> <20120104071658.GR2742@adacore.com> 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/msg00005.txt.bz2 > Isn't the following at least slightly better? > > (gdb) b foo.c:100 > No line 100 in file "foo.c". > Make breakpoint pending on future load of shared library > containing "foo.c" where this line is valid? (y or [n]) n I see what you are trying say. I don't have a strong opinion and I would not object, but I do prefer the previous phrasing. Also, I do not see why we would have to treat this case specially. I think that if we change for this case, we should change for every type of error. And lastly, one the pragmatic side, this is going to screw up all the testcases as well as front-end that might be matching the old output. This is a weak argument, but it is true nonetheless. -- Joel