From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32070 invoked by alias); 26 Jul 2011 19:53:32 -0000 Received: (qmail 32061 invoked by uid 22791); 26 Jul 2011 19:53:31 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 26 Jul 2011 19:53:17 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6QJrHsu020830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Jul 2011 15:53:17 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6QJrGSt004222; Tue, 26 Jul 2011 15:53:17 -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 p6QJrFmd030178; Tue, 26 Jul 2011 15:53:16 -0400 From: Tom Tromey To: 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> Date: Tue, 26 Jul 2011 21:06:00 -0000 In-Reply-To: (Tom Tromey's message of "Fri, 01 Jul 2011 10:39:00 -0600") 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/msg00742.txt.bz2 First of all, pinging Pedro -- I would greatly appreciate your commentary to help unblock this project. Tom> I propose a simple rule for the handling of ambiguous linespecs: a Tom> breakpoint whose argument is ambiguous will fire at all matching Tom> locations. This rule has several properties that I consider desirable: Tom> * It is simple to explain to users Tom> * It is predictable Tom> * It is time-invariant Tom> * It is implementable ;-) This week while discussing this and other things on irc, we came up with a possible problem with the proposal: it interacts poorly with lazy debuginfo reading. Right now there are several patches (and planned patches) to make debuginfo reading lazier: my lazy reading patch for new inferiors, Sergio's work, and Gary and Paul both have work in this area too. These all rely on the idea that, generally, loading a new .so doesn't mean that we must necessarily read its debuginfo. However, with the plan as proposed, GDB will in most cases become much less lazy-capable. While the proposal addresses this in part by letting users specify breakpoint locations more precisely, this will not happen by default -- "break main" will still mean loading all the debuginfo for everything gdb sees. So, a slightly different approach to solving this would be to make breakpoints capture their location set at the "point of resolution" -- either immediately, or for a pending breakpoint, the first time it hits. Then, provide some additional syntax to make a "permanently pending" breakpoint. This approach would provide efficiency by default ("break main" would typically resolve to a single location, not requiring any extra debuginfo reads in the future) with an option for a more dynamic approach for those circumstances requiring it. I am not completely sold on this, but I wanted to float the idea for comments. I think this might imply some cleanup of the current breakpoint re-setting approach. Tom