From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23734 invoked by alias); 5 Jul 2011 19:52:10 -0000 Received: (qmail 23724 invoked by uid 22791); 5 Jul 2011 19:52:09 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jul 2011 19:51:50 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p65Jpcpo018909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 15:51:38 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p65JpbFL009003; Tue, 5 Jul 2011 15:51:37 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p65Jpac3020695; Tue, 5 Jul 2011 15:51:36 -0400 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC] canonical linespec and multiple breakpoints ... References: <20110505162855.GA2546@adacore.com> <83bozgmhil.fsf@gnu.org> <83k4dcd1bh.fsf@gnu.org> <20110704192005.GQ2407@adacore.com> Date: Tue, 05 Jul 2011 19:53:00 -0000 In-Reply-To: <20110704192005.GQ2407@adacore.com> (Joel Brobecker's message of "Mon, 4 Jul 2011 12:20:05 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00167.txt.bz2 Joel> I think that this is a good general rule, and something we should Joel> encourage our users to use. But it seems that it does not cover Joel> the case where 'set multiple-symbols ask' is in use, does it? Joel> My understanding, when `ask' is that, if the user selects `all', Joel> then we're in the case above (fire at all locations, add new locations Joel> as we discover them), but if the user selects a sub-sets of the Joel> potential matches, what should we do? Joel> My suggestion, in that case, is to make the list of selected Joel> locations static. In other words, we do not add new locations Joel> as they get discovered. This was part of the proposal but I think it should have been more prominent. My proposal was that in 'ask' mode, 'break' makes a separate canonicalized breakpoint for each location the user requests. I had proposed making the 'all' choice make N different breakpoints, each "static". But now I think that 'all' should mean "make a dynamic breakpoint covering all locations", and the user can create separate static breakpoints by entering "2-57" (e.g.) at the prompt. This gives the user a way to achieve multiple-symbols=all behavior without having to temporarily change the setting. I think we must specify what "static" means -- by specifying the canonicalization algorithm. When I consider the difference between your proposal and Jerome's, I think the distinction largely relies on what exactly it means to canonicalize a location. FWIW I would be satisfied with any of several possible solutions (including yours and Jerome's) to the multiple-symbols=ask scenario. Joel> The typical scenario is when we have multiple instantiations of Joel> a given generic, and the user is only interested in debugging Joel> one, or at least a small subset. In that case, a typical user Joel> debugging using a GUI or an IDE will click on the code, which Joel> is often translated into a FILE:LINE linespec. Do IDEs actually run in multiple-symbols = ask mode? My understanding was that these interactive prompts caused headaches for MI users. Tom> In order to properly re-set breakpoints, we need a canonical form of the Tom> linespec. Currently this is done by constructing a new canonicalized Tom> linespec. In my proposal we will replace this with a structure, the Tom> better to add more precise behavior without needing to construct Tom> linespec syntax for every possible case. E.g., we can have a bit Tom> indicating whether this canonical linespec matches symbols without Tom> debuginfo. Joel> I think it's important to have some kind of canonical form that Joel> the user's can use as the linespec as well. That way, they can Joel> enter a linespec that, in the vast majority of cases, is not Joel> ambiguous. For our purposes, FILE:FUNCTION:LINE has worked really Joel> well... When I wrote this I was specifically thinking of the situation where a breakpoint has some matches with debuginfo and some without. I didn't see much value in having a linespec covering the "functions named X without debuginfo" case. FILE:FUNCTION:LINE makes sense to me, I think it would be useful for C++ templates as well. Tom> 4. Set a pending breakpoint. Tom> (gdb) break lib_function Tom> 5. The same, but the pending name is ambiguous. Tom> These both make a pending breakpoint; inferior changes may cause Tom> locations to be added or removed. Joel> So, pending breakpoints are implicitly treated as breakpoints Joel> with multiple-symbols set to `all', right? I think that'd be fair. Yes. Tom