From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11156 invoked by alias); 2 Aug 2011 15:33:24 -0000 Received: (qmail 11134 invoked by uid 22791); 2 Aug 2011 15:33:22 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_BJ X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Aug 2011 15:33:08 +0000 Received: (qmail 30151 invoked from network); 2 Aug 2011 15:33:07 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Aug 2011 15:33:07 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] canonical linespec and multiple breakpoints ... Date: Tue, 02 Aug 2011 15:33:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: Tom Tromey References: <20110505162855.GA2546@adacore.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108021633.04777.pedro@codesourcery.com> 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-08/txt/msg00028.txt.bz2 On Tuesday 26 July 2011 20:53:15, Tom Tromey wrote: > First of all, pinging Pedro -- I would greatly appreciate your > commentary to help unblock this project. I'm very sorry for the delay in responding to this. It turns out the world didn't stop when I went on vacation, for some unknown reason, and I've took a long time to catch up... I wanted to read the whole discussion and think at least a bit before replying... I'm sold on going your proposed direction, and forgetting the 3-level breakpoints approach. I believe it provides a similar experience to what TotalView users are used to, FWIW. > > 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 Okay, agreed. > Tom> * It is implementable ;-) :-) I think breakpoint_ops'ing all things would make 3-tier easier, but that's moot now. > > 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. I don't think it's a good idea to confuse the user interface design with some optimizations. I'd rather we have "correct" before "optimized". "unsurprising" before "super fast". > Right now there are several patches (and planned patches) to make > debuginfo reading lazier: my lazy reading patch for new inferiors, I never replied to your patch, but my reaction was that it is probably breaking breakpoints in the new inferiors today, even without any linespec/multi breakpoints work. Wouldn't e.g., making debug info reading smarter (the sharing of objfiles between inferiors work/idea?) mostly dispense that approach? It's not just user breakpoints that worry me with simply avoiding debug info altogether with some per-inferior flag, rather than making it depeng on need/request. E.g., activating thread library debugging usually needs at least minimal symbols. Another example, GDB currently only invites the remote end to ask if it wants GDB to resolve some symbols (qSymbol) after loading the objfile. With a lazy scheme, we should let the remote end know (send it a qSymbol) there's potentially new symbols available, even if we haven't yet read the debug info. If the remote end replies with a request, we can read the debug info then. > 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'm not sold on this either. One could do something similar, but leavy the default the way around -- have a new "final" property/option of breakpoints --- once it's spec resolves, it no longer gets locations auto-added, and have the user request for final'ness explicitly. The "final" property does not need to be final itself, it could be toggleable. What I don't think I have seen addressed is how the proposal interacts with multi-exec. E.g, suppose I have program foo loaded once (one inferior) and program bar loaded twice (two inferiors). I have one of the bar inferiors in focus, and I do "b main". How many locations does this resolve to? One, two, or three? Currently, it resolves to two. > > I think this might imply some cleanup of the current breakpoint > re-setting approach. -- Pedro Alves