From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9484 invoked by alias); 2 Aug 2011 17:09:11 -0000 Received: (qmail 9473 invoked by uid 22791); 2 Aug 2011 17:09:10 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BJ 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, 02 Aug 2011 17:08:56 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p72H8mXd004702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 13:08:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p72H8mM7032165; Tue, 2 Aug 2011 13:08:48 -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 p72H8khY030711; Tue, 2 Aug 2011 13:08:46 -0400 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC] canonical linespec and multiple breakpoints ... References: <20110505162855.GA2546@adacore.com> <201108021633.04777.pedro@codesourcery.com> Date: Tue, 02 Aug 2011 17:09:00 -0000 In-Reply-To: <201108021633.04777.pedro@codesourcery.com> (Pedro Alves's message of "Tue, 2 Aug 2011 16:33:04 +0100") 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-08/txt/msg00032.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> I'm very sorry for the delay in responding to this. It is no problem, and thanks for replying. Tom> Right now there are several patches (and planned patches) to make Tom> debuginfo reading lazier: my lazy reading patch for new inferiors, Pedro> I never replied to your patch, but my reaction was that it is Pedro> probably breaking breakpoints in the new inferiors today, even Pedro> without any linespec/multi breakpoints work. Is there a way to set a breakpoint in a new inferior without first loading the debuginfo by hand? It has been a while since I was looking at this, but I don't remember finding a way. If there is one, though, I can easily test this. Pedro> Wouldn't e.g., making debug info reading smarter (the sharing of Pedro> objfiles between inferiors work/idea?) mostly dispense that Pedro> approach? That would help for much of the debuginfo, but not all of it. I think it would depend on how much sharing there is across inferiors in a given session. FWIW I have taken a couple stabs at making objfile sharing work. It is a lot harder than I thought it would be, and it winds up requiring conditions which I am not confident are always true. The big problem comes from symbols. In the new setup, symbols are independent of the program space. SYMBOL_VALUE_ADDRESS still needs the program space, though -- so we add a mapping from objfile to the per-program-space objfile wrapper. But, to actually use this map, the current program space must be set properly at any use of SYMBOL_VALUE_ADDRESS. It isn't clear to me that this is guaranteed. I think there are other cases like this too. Pedro> It's not just user breakpoints that worry me with simply avoiding Pedro> debug info altogether with some per-inferior flag, rather than Pedro> making it depeng on need/request. [...] Thanks, this is very helpful info. Pedro> I'm not sold on this either. One could do something similar, Pedro> but leavy the default the way around -- have a new "final" Pedro> property/option of breakpoints --- once it's spec resolves, Pedro> it no longer gets locations auto-added, and have the user Pedro> request for final'ness explicitly. The "final" property Pedro> does not need to be final itself, it could be toggleable. Ok. I will implement it the "full" way first; if we find it isn't so good in practice we can always change it or add an option later on. Pedro> What I don't think I have seen addressed is how the proposal Pedro> interacts with multi-exec. E.g, suppose I have program foo Pedro> loaded once (one inferior) and program bar loaded twice (two Pedro> inferiors). I have one of the bar inferiors in focus, Pedro> and I do "b main". How many locations does this resolve to? Pedro> One, two, or three? Currently, it resolves to two. Three, following the rule that a breakpoint will fire at all matching locations. Tom