From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13793 invoked by alias); 8 Jun 2011 14:43:32 -0000 Received: (qmail 13758 invoked by uid 22791); 8 Jun 2011 14:43:31 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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; Wed, 08 Jun 2011 14:43:11 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p58EhBtD007358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Jun 2011 10:43:11 -0400 Received: from host1.jankratochvil.net (ovpn-113-49.phx2.redhat.com [10.3.113.49]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p58Eh9xc003642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2011 10:43:10 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p58Eh8RE001813; Wed, 8 Jun 2011 16:43:08 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p58Eh7QF001808; Wed, 8 Jun 2011 16:43:07 +0200 Date: Wed, 08 Jun 2011 14:43:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [patch 0/2] physname reg.: C++ breakpoints / linespec fixes Message-ID: <20110608144307.GA32073@host1.jankratochvil.net> References: <20110605202615.GA20427@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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-06/txt/msg00109.txt.bz2 On Tue, 07 Jun 2011 22:23:53 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > > Jan> linespec is IMNSHO a hack anyway and one day it should be merged > Jan> with the general expression parser (used for example for `print'); > Jan> which should be further merged with GCC/G++ parser. Expression > Jan> Parser Plug-In Available > Jan> http://sourceware.org/ml/archer/2011-q1/msg00122.html > > I am not sure this is the right direction. I have a few issues with it. > > First, it seems to me that we'll always have to keep some part of > linespecs around, because 'break file:line' is important. So, we'll > always have to look at the argument in multiple ways and decide what to > do. The `line' case is sure not useful for expressions. But for example `file:func' is currently implemented only in linespec and it should be supported even by expressions - see the bottom example. The `file:line' could be implemented as a special expression as otherwise all the parsing and escaping of the possibly whitespaced `file' part would have to be implemented twice and we would get to the same pain. > Second, I suspect this ties linespecs too closely to the current language. > It seems reasonable to me for 'break ns::func()' to work in a C frame. C++ is generally backward compatible with C, I do not find some problems with fallback to this or that language if the other language parsing gave an error. For the special cases of some valid parsing in both languages but ambiguous due to some overloaded C++ operators one can require proper `set language' to be set. One can face it only in some heavily overloaded projects (like Mozilla IIRC) and the developers would be aware of it. > Third, IIRC your branch is based on the idea of the parser constructing > an expression, which is then decoded (or evalled?) to find the correct > symbol. I think this approach neglects the possibility that a linespec > could be ambiguous, another hot topic. Debugger could handle some way even possibly-ambigous expressions. `print funcname' depends on context and the debugger user is IMO not so strictly aware of the current context like the programmer is. Thanks, Jan ==> a/f.c <== static void f (void) {} void x (void) { f (); } ==> b/f.c <== static void f (void) {} void y (void) { f (); } ==> m.c <== extern void x (void); extern void y (void); int main (void) { x (); y (); return 0; } gcc -o m a/f.c b/f.c m.c -Wall -g (gdb) b a/f.c:f Breakpoint 1 at 0x400478: file a/f.c, line 1. (gdb) b b/f.c:f Breakpoint 2 at 0x40048c: file b/f.c, line 1. (gdb) b f Note: breakpoint 2 also set at pc 0x40048c. Breakpoint 3 at 0x40048c: file b/f.c, line 1. (gdb) p f $1 = {void (void)} 0x400488 (gdb) p a/f.c:f No symbol "a" in current context. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = it should work. (gdb) p b/f.c:f No symbol "b" in current context. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = it should work.