From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26783 invoked by alias); 9 Nov 2011 19:00:00 -0000 Received: (qmail 26773 invoked by uid 22791); 9 Nov 2011 18:59:59 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Nov 2011 18:59:45 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 06F052BB3DF; Wed, 9 Nov 2011 13:59:45 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Eb92S3fDAiMD; Wed, 9 Nov 2011 13:59:44 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AFAB32BB3DA; Wed, 9 Nov 2011 13:59:44 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 29123145615; Wed, 9 Nov 2011 13:59:35 -0500 (EST) Date: Wed, 09 Nov 2011 19:00:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Jerome Guitton , Jan Kratochvil , gdb-patches@sourceware.org, Paul Hilfinger Subject: Re: RFA: implement ambiguous linespec proposal Message-ID: <20111109185935.GQ14508@adacore.com> References: <20111028221459.GA28467@host1.jankratochvil.net> <20111104074543.GA13839@host1.jankratochvil.net> <20111109160529.GO14508@adacore.com> <20111109175623.GP14508@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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-11/txt/msg00252.txt.bz2 > I think FILE:FUNCTION:LINE is a good form to provide to users, but it > seems to me that it is incorrect to rewrite a user's "FUNCTION" linespec > into this form. My reason is that it seems like it would do the wrong > thing if the line number changes -- the linespec would stop working, > rather than re-evaluate correctly. How do you deal with this problem? Touche :-)! We do not deal with that issue. It hasn't been a real problem so far, but it would be nice to have it solved nonetheless. > Joel> The question is, can we use that same form for everyone? I thought > Joel> you were going to do unconditional rewriting of the location string, > Joel> but now I'm not so sure anymore... > > With my patch, only relative forms require rewriting. I think those are > just "break LINE" and "break LABEL". The former is rewritten to > FILE:LINE, and the latter to FUNCTION:LABEL. OK, this makes sense. > With multiple-symbols=ask, we also do filtering based on the "canonical > form", which is different from the string used to re-evaluate. > > E.g., suppose you do "break something::method" and there are 5 methods. > Suppose you have multiple-symbols=ask and you pick something::method(int). > Then, we will have a breakpoint whose linespec is "something::method" > but whose filter is "something::method(int)". I wonder if we could start filtering based on function fully qualified name, and profile (argument types) as well. In other words, if the user does: (gdb) break foo and there are several functions named foo, then we'd have a filter that says: package1.foo(integer) package2.instantiation.foo(float) (etc). I think that might work, but I'll discuss it with Paul Hilfinger. The only road-block I can foresee is the fact that I am unclear on the resolution rules in Ada. I think they can get quite tricky, and reproducing that in GDB might be a fair amount of work (if possible at all). On the other hand, it would be nice to have that, because we somewhat have something like that already for resolving inferior function calls from GDB, but it's fairly primitive, and I think we can call the wrong function sometimes (I just forgot the details). Just curious: Are we planning on emitting a warning if re-evaluating a breakpoint for which we no longer have a match for one of the entries in the filter? This would happen if the user selected a function which, after rebuilding the executable, no longer exists... > I chose this somewhat odd design over the more straightforward > rewriting of the linespec because there are canonical forms which are > not yet suitable as input to linespec. I actually like this design better. In fact, we don't even need the filter to consist of strings. It could very well be something more elaborate... -- Joel