From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26065 invoked by alias); 13 Jan 2006 13:05:01 -0000 Received: (qmail 26051 invoked by uid 22791); 13 Jan 2006 13:04:59 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jan 2006 13:03:58 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-246-138.inter.net.il [84.228.246.138]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DJE20755 (AUTH halo1); Fri, 13 Jan 2006 15:03:53 +0200 (IST) Date: Fri, 13 Jan 2006 13:05:00 -0000 Message-Id: From: Eli Zaretskii To: Joel Brobecker CC: hilfingr@gnat.com, gdb@sourceware.org In-reply-to: <20060113115647.GG10275@adacore.com> (message from Joel Brobecker on Fri, 13 Jan 2006 15:56:47 +0400) Subject: Re: [RFC] multiple breakpoints from FILE:LINE Reply-to: Eli Zaretskii References: <20060113104212.0B28848CBD8@nile.gnat.com> <20060113115647.GG10275@adacore.com> 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-01/txt/msg00105.txt.bz2 > Date: Fri, 13 Jan 2006 15:56:47 +0400 > From: Joel Brobecker > Cc: Paul Hilfinger , gdb@sourceware.org > > > I'm not sure I understand: why isn't something.adb:12 enough to > > specify the breakpoint location unambiguously? > > This is because you may have several instances of the same line. Imagine > that you have an inlined function defined at foobar.c:12. The function > body is duplicated at each call of the function. If the user asks to > insert a breakpoint at this line, which instance/address should the > debugger use? How about something like break something.adb:12 if SOME_CONDITION where SOME_CONDITION is something we should invent to specify the instance where we want to put the single breakpoint? This has the advantage of using an existing syntax, especially if the condition could be made to use some convenience variable. By contrast, what you suggest modifies the syntax of a location specification; do we really want that?