From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2051 invoked by alias); 8 Feb 2011 21:42:31 -0000 Received: (qmail 2043 invoked by uid 22791); 8 Feb 2011 21:42:31 -0000 X-SWARE-Spam-Status: No, hits=-6.8 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; Tue, 08 Feb 2011 21:42:24 +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 p18LgNUK017084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Feb 2011 16:42:23 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p18LgNwU017038; Tue, 8 Feb 2011 16:42:23 -0500 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 p18LgM7e032316; Tue, 8 Feb 2011 16:42:22 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 12AE837817D; Tue, 8 Feb 2011 14:42:22 -0700 (MST) From: Tom Tromey To: Jan Kratochvil Cc: Keith Seitz , gdb-patches@sourceware.org Subject: Re: [patch 0/3] Re: [RFA] c++/11734 revisited (and c++/12273) References: <4D002672.5090504@redhat.com> <4D07CD68.5000700@redhat.com> <20110206224548.GA5000@host1.dyn.jankratochvil.net> Date: Tue, 08 Feb 2011 21:42:00 -0000 In-Reply-To: <20110206224548.GA5000@host1.dyn.jankratochvil.net> (Jan Kratochvil's message of "Sun, 6 Feb 2011 23:45:48 +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-02/txt/msg00181.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> If the code should be nice I tried archer-jankratochvil-linespec where Jan> linespec is based on the expressions. Noted by Daniel Jacobowitz before: Jan> http://sourceware.org/ml/gdb-patches/2009-11/msg00266.html I think this would be a good direction to head. One difficulty is that, right now, linespecs for one language often work while the current language is set to something else. This doesn't work for Java, I think, but I think that is the point of the Objective C hooks in linespec.c. I'm not sure this is important enough that it is worth the maintenance headache we have with linespecs. Jan> It still has some regressions but the most common C++ cases work Jan> there and I find it doable with some more time (mostly if the error Jan> messages can be changed). As long as the messages make sense to the user, I think the wording is negotiable. Jan> The are problems with: Jan> * expression evaluator cares about the function value (=address) where the Jan> function symbol for linespec is already dropped. Jan> * linespec should have no side effects. But the expression evaluator's Jan> EVAL_AVOID_SIDE_EFFECTS mode cares only about types, not about values. It would be useful in other situations to be able to disable side effects but still evaluate an expression. I think there was a bug report requesting this for GUIs, but I am not sure. It would be nice if we could limit the parser to just consider names. Maybe instead of evaluating the expression we could examine it and extract the information we need from the parsed form. Or, just make a new language entry point and make each language do this internally. Tom