From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1451 invoked by alias); 29 Apr 2011 20:42:10 -0000 Received: (qmail 1438 invoked by uid 22791); 29 Apr 2011 20:42:09 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,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; Fri, 29 Apr 2011 20:41:46 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3TKfbI9026241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2011 16:41:37 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3TKfbve021872; Fri, 29 Apr 2011 16:41: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 p3TKfaZS029877; Fri, 29 Apr 2011 16:41:36 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 0794D378304; Fri, 29 Apr 2011 14:41:35 -0600 (MDT) From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org, Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' References: <201104121218.08910.pedro@codesourcery.com> <201104181938.28644.pedro@codesourcery.com> Date: Fri, 29 Apr 2011 20:42:00 -0000 In-Reply-To: <201104181938.28644.pedro@codesourcery.com> (Pedro Alves's message of "Mon, 18 Apr 2011 19:38:28 +0100") 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-04/txt/msg00567.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: [...] Pedro> This is why I proposed in the response to Jan, that if we want Pedro> to group different "_source_ locations" under the same breakpoint, Pedro> we implement it as a 3rd hierarchy, so you'd get: Ok, I think I mostly understand this proposal. I would like to work through this and come to some agreement, since I am planning to implement the result -- not just for SystemTap probes but also because I recently starting looking at an ambiguous name feature request we've had open in RH bugzilla for far too long. My current understanding is that an ambiguous linespec should cause `break' to make a new "3rd-tier" breakpoint with sub-breakpoints for each separate source location. These sub-breakpoints would have canonicalized linespecs for better stable naming. Furthermore they would be created and destroyed automatically in response to inferior changes. FWIW, I tend to think the 3-tier solution is too complicated. I think having two ways that a breakpoint can have multiple locations will confuse users. Also, I came up with some cases I don't understand; I feel certain there are more lurking. Suppose the user does `break function' where `function' is *not* ambiguous. This makes an ordinary breakpoint. Now suppose the inferior calls dlopen and the new library has a definition of `function'. What happens? 1. Breakpoint changes from ordinary to 3-tier. 2. We add logic to canonicalize the existing breakpoint's linespec and do not set a new breakpoint. 3. We didn't make an ordinary breakpoint after all, all breakpoints are 3-tier. Choice 1 seems potentially weird, though maybe it would work ok? Choice 2 seems bad in some circumstances. `function' might be inlined in some places, in which case you would actively want new breakpoint locations to be set. Choice 3 introduces complexity for all uses even though most breakpoints aren't in fact ambiguous. Here is an oddity: consider `break probe:something'. Now suppose this probe was used in multiple locations -- one having debuginfo and two not having debuginfo. I think this implies that a 3-tier breakpoint must have one special sub-breakpoint that collects locations from debuginfo-less matches. Or perhaps each could be given its own sub-breakpoint -- but there is no sensible way to provide canonical linespecs here, so matching won't really work. Suppose the inferior uses dlmopen and loads the same library twice. Now there is really no way to canonicalize a linespec -- it can't even be objfile-relative (postulate for a moment that there is a syntax for this). I think most of these cases are readily resolveable with the "break at all matching locations" approach: * Unambiguous -> ambiguous transition is no problem. Breakpoint condition may no longer parse -- not super, but workable. (As an aside: seeing those "can't parse" messages has bugged me in the past, it seems like it would be good to have a way to tell GDB "if you can't parse it, please stop right away so I can fix the darn thing".) * The no-debuginfo SystemTap probe case: no problem in itself, and we could simply mandate that such a breakpoint can only have certain expressions attached (also mentioned below). * dlmopen. Also no problem, the user asked for it :) One advantage of 3-tier is that it does let you put different conditions on different sub-breakpoints. (But the general idea of the simpler approach is that you should disambiguate if you want tight control. Which gives me the idea that we could make a new break command that does just does automatically.) I think either case will need some expansion of the matching heuristic for breakpoints, and maybe some linespec additions to make it possible to disambiguate more cases. I am not very concerned about the MI problem. We can emit a new field holding a vector of file:line locations, or something like that. Front ends will adapt. [...] Pedro> You still have manifestations of the same problem. Location numbers are Pedro> supposed to be stable. For example, users can enable/disable locations Pedro> individually. This problem is fundamental, just because there is no stable name for source locations in the face of changes to the source. We are always going to have heuristics in GDB, and some losing cases. Pedro> See, "bp_location" concerns with address locations while the user Pedro> the user is concerned about "source locations". I think that Pedro> if "bp_location" had been named "bp_compiled_address", we wouldn't Pedro> be having this discussion. :-) For the SystemTap probe case in particular, I am not so sure. I mean, I can see how it would be useful to an MI consumer if GDB emitted file:line locations for all the locations hit by a "probe:" breakpoint. This is not fundamental to one approach or the other, it can be made to work. I think it would be a reasonable choice on our part to simply mandate that a SystemTap probe breakpoint have a single condition (for all locations) which could only refer to globals and probe arguments. Pedro> It's not necessarily a bad thing (and not necessarily a good thing Pedro> either). If you have a big project, with a bunch of static Pedro> "foo" functions, it's not unreasonable to have "b foo" Pedro> break at the "closest" function with that name in your context. Sure, but that isn't what actually happens. And, this would require separate thinking. Like, suppose the "closest" metric yields an ambiguous result, what should happen? Pedro> What would "list parse_number" do if "break parse_number" breaks Pedro> in all the instances of that static function? Error or give a menu. Tom