From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30934 invoked by alias); 2 Jul 2011 06:35:59 -0000 Received: (qmail 30788 invoked by uid 22791); 2 Jul 2011 06:35:58 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 02 Jul 2011 06:35:44 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LNP00A000VM6W00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Sat, 02 Jul 2011 09:35:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.228.8.216]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LNP009AJ0ZHYV40@a-mtaout22.012.net.il>; Sat, 02 Jul 2011 09:35:43 +0300 (IDT) Date: Sat, 02 Jul 2011 06:35:00 -0000 From: Eli Zaretskii Subject: Re: [RFC] canonical linespec and multiple breakpoints ... In-reply-to: To: Tom Tromey Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fwmpqjem.fsf@gnu.org> References: <20110505162855.GA2546@adacore.com> <83bozgmhil.fsf@gnu.org> <83k4dcd1bh.fsf@gnu.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00064.txt.bz2 > From: Tom Tromey > Date: Fri, 01 Jul 2011 10:39:00 -0600 > > Here is my proposal for how to handle ambiguous linespecs. Thanks. > I think I/T sets are also a good idea here What is an "I/T set"? > Tom> 6. Set a breakpoint that has a match in the inferior. Then the inferior > Tom> loads a .so to make the linespec ambiguous. > > Add new locations to the breakpoint. How about alerting the user to this effect, giving them an opportunity to narrow the scope of the breakpoint? We could have this as an optional behavior, but IMO if the breakpoint was unambiguous when I set it, I would like such an alert by default, because it could be that I knew what I was doing, and GDB might be defeating me now. OTOH, if the new-and-improved linespec will allow me to be specific about this use case (i.e. I don't want any other locations be added), perhaps this is not an issue. On the third hand, I could be forgetting something when I specify the breakpoint, and still be surprised. > modify breakpoint N location LINESPEC I think this kind of command is necessary not only for the use case which led you to conclude that it's needed. We need this to let the user re-specify location based on dynamically changing environment of the debugging session: shared libraries being loaded and unloaded, inferiors starting and exiting, etc. (As for the command name, I'd suggest "location N LINESPEC", btw.) I would also recommend an option to stop and suggest such changes whenever any event happens that would normally trigger addition of another location, but _before_ such a location is added -- e.g., because putting a breakpoint on some locations has undesirable side effect, like in embedded systems. IOW, we should give the user more control on the precise linespec, including when the original linespec turns out to be different from what it was when typed. You say nothing about watchpoints. Will they also use the same infrastructure? > I welcome contrasting proposals Sorry, I don't have any ;-) Thanks again for working on this.