From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16186 invoked by alias); 26 May 2011 21:06:15 -0000 Received: (qmail 16174 invoked by uid 22791); 26 May 2011 21:06:13 -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; Thu, 26 May 2011 21:05:52 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4QL5bZl005567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 May 2011 17:05:37 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4QL5bqs024930; Thu, 26 May 2011 17:05:37 -0400 Received: from opsy.redhat.com (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 p4QL5a5D029838; Thu, 26 May 2011 17:05:36 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id EACB43781A7; Thu, 26 May 2011 15:05:35 -0600 (MDT) From: Tom Tromey To: Eli Zaretskii Cc: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [RFC] canonical linespec and multiple breakpoints ... References: <20110505162855.GA2546@adacore.com> <83bozgmhil.fsf@gnu.org> Date: Thu, 26 May 2011 21:06:00 -0000 In-Reply-To: <83bozgmhil.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 May 2011 10:10:10 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-05/txt/msg00623.txt.bz2 Tom> While looking into this area I made a list of difficulties and Tom> considerations that I know of. I can write that up in a readable form Tom> if you think that would help. Eli> Please do, and thanks. Here are the issues I know of. I am not convinced that there is any good way to get all the desirable features into a single model, but I welcome brainstorming to this end. I'm sorry this is so disorganized. It resisted attempts by me to make it more orderly. I can try to flesh out any pieces that don't make sense, or come up with difficult scenarios when something isn't clear. First, there really is a problem. I think it is worth pointing this out. Currently, given an ambiguous linespec, GDB picks a winner. This winner is unpredictable. Right now only a `file:line' breakpoint can have multiple locations. This is convenient for MI, though the problems here are fixable. I think this does also give a somewhat nice story for users when the inferior changes; often (but not always) locations can be preserved, and `file:line', especially once canonicalized, is reasonably unambiguous, even across objfiles. Tracking locations like this is desirable because it means particular instances can be enabled or disabled and the user can have some reasonable expectation that gdb will do the right thing across re-runs, etc. Note that the existing code here can be confounded in some situations: macrology for sure, maybe different template instantiations (but I didn't try this one particularly). Breakpoint conditions interact with multi-location breakpoints. A condition needs a scope in which to parse. A breakpoint that can truly be multi-location could acquire a new location that invalidates previous parses. In the particular case of SystemTap probe points, I think it would be ok to require multi-location breakpoint conditions to just use the global scope plus any arguments passed to the probe. Commands also interact with multi-location breakpoints, but less significantly than conditions. With a 3-tiered approach I wonder whether it makes sense to attach commands at both outer tiers? Or just the outermost? Canonicalization is an important problem to solve. It matters at least for the menu-choosing case, should we keep that. I think Matt Rice hit on the right idea here: instead of always canonicalizing to a linespec, have some internal object that holds more state. We probably also need some new kind of linespec in order to let the user more precisely filter locations. It is worth thinking about what "the same" means when it comes to two linespecs (or canonicalized objects). E.g., consider "break function". Is "function" the same across objfiles? If so or not so, what is the rationale? For example, "function" might be an inline function defined in a header, and so really should be treated the same across objfiles; or maybe this case requires further filtering based on file:line. Maybe different sorts of linespecs require different comparators. One consideration is what "the same" means when one location has debuginfo and another does not. Per an earlier email, I think this negatively affects the 3-tier approach. It is worth thinking about "time invariance". E.g., suppose we adopt Jerome's "menu" plan. In this case, an ambiguous linespec can present the user with a menu (depending on a setting). But what happens if a linespec is not ambiguous, but then becomes ambiguous due to changes in the inferior? Time invariance and canonicalization also affects the multi-inferior case. The current plan is to handle multi-inferior breakpoints using I/T sets; but it seems to me that these may match names in different ways across inferiors. A simple example is just `break [*] main' -- this either makes a single breakpoint (with all the attendant true multi-location problems), or binds eagerly (contra the `[*]' spec), or introduces a tiered breakpoint (but with a more complex example perhaps one requires 4 tiers? It is unclear to me). FWIW, on `archer-tromey-multi-breakpoint-2' I implemented a simple form of multi-tiered breakpoints for the multi-inferior case. On this branch there is a new "multi break" command that makes a new kind of breakpoint; this breakpoint is re-evalled for each matching inferior as it is created, and may then create a new real breakpoint. You can try it out if you are curious; I think it worked ok, but not truly great (better would have been making it a real kind of breakpoint so it could have commands and whatnot). Many commands, not just "break", use linespecs. What I found was: list, edit, func, tfind, and clear. Also linespec is called by select_source_symtab, but I think only for "main" (so could be done differently). Any solution has to deal with these commands in some way. Linespecs are exposed to Python, so some updates are required there. I don't think this is too big a problem. It is probably worth writing a Python API to whatever canonicalized form exists. Tom