From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1598 invoked by alias); 30 Mar 2004 14:27:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1548 invoked from network); 30 Mar 2004 14:27:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Mar 2004 14:27:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B8KCf-0004qX-6B; Tue, 30 Mar 2004 09:26:57 -0500 Date: Tue, 30 Mar 2004 14:27:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add language-dependent post-parser Message-ID: <20040330142656.GA18340@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , gdb-patches@sources.redhat.com References: <20040330092413.2E716F281D@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040330092413.2E716F281D@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00746.txt.bz2 On Tue, Mar 30, 2004 at 04:24:13AM -0500, Paul Hilfinger wrote: > > Ping. I have not yet received a reply to my last message on this > proposed patch (submitted Thu, 4 Mar 2004 06:33:45 -0500 (EST), with > a followup message on Fri, 5 Mar 2004 03:15:26 -0500 (EST)). As a reminder, > I've appended the discussion preceding the original patch and my response to > Daniel. Hi Paul, I was actually hoping that someone else would comment. I'm not fond of this solution (it's a little too much of working around GDB rather than fixing GDB), but that's not a very strong opinion. Could you explain this bit a little more? > determining the static types of the arguments. While it is possible > to do so during parsing, it would mean partially rebuilding the > existing infrastructure that allows GDB to compute types and expression > values. We thought it would be easier to operate on the same prefix I don't see why you can't do it, for instance, here: simple_exp : simple_exp '(' arglist ')' { write_exp_elt_opcode (OP_FUNCALL); write_exp_elt_longcst ($3); /* check arguments */ write_exp_elt_opcode (OP_FUNCALL); } ; You'd have to wiggle the expression machinery to give you back the expression node for the function name, probably by making the write_exp_* functions return a pointer. But that's less intrusive and more efficient than adding a second pass. > > Paul Hilfinger > > Original message of 4 March (minus patch): > > For Ada, we found it convenient to do a name-resolution pass after parsing and > before evaluation of expressions. The most convenient form on which to > perform this resolution is the prefix form (that way, we can use the usual > type-computing machinery already included in expression evaluation). > Unfortunately, prefixification occurs after and separate from parsing. > The obvious thing to do was to add a function to the language vector for > post-parsing. For most languages, it does nothing. The patch below > does most of the work in inserting this hook, including the introduction > of a parse-in-type-context function that provides a type context for > the post-parser. In its current form, this patch is a NOP that merely > provides the hooks. > > Paul Hilfinger > > 2004-03-04 Paul N. Hilfinger > > * language.h (language_defn): Add new la_post_parser field. > * parser-defs.h (null_post_parser): New declaration (default for > la_post_parser). > > * parse.c (parse_exp_1): Move code to parse_exp_in_context and > insert call to that function. > (parse_exp_in_context): New function, including code formerly in > parse_exp_1. Calls language-dependent post-parser after > prefixification. > (parse_expression_in_context): New exported function. > (null_post_parser): New definition. > * expression.h (parse_expression_in_context): Add declaration. > > * p-lang.c (pascal_language_defn): Add trivial post-parser. > * c-lang.c (c_language_defn): Ditto. > (cplus_language_defn): Ditto. > (asm_language_defn): Ditto. > (minimal_language_defn): Ditto. > * f-lang.c (f_language_defn): Ditto. > * jv-lang.c (java_language_defn): Ditto. > * language.c (unknown_language_defn): Ditto. > (auto_language_defn): Ditto. > (local_language_defn): Ditto. > * m2-lang.c (m2_language_defn): Ditto. > * scm-lang.c (scm_language_defn): Ditto. > * obj-lang.c (objc_language_defn): Ditto. > > ------------------------------------------------------------ > > My reply to Daniel Jacobowitz of 5 March: > > > Could you explain more about why you found this necessary? It's hard > > to evaluate the patch without that. > > Daniel, > > Sure. In Ada mode, we handle overloaded functions (not just those > that are the Ada equivalent of member functions). More precisely, we > resolve overloading that can be resolved bottom-up, as C++ (almost > always) does. The issue we encountered was the point at which GDB > discovers it cannot resolve the overloading. > > With a command such as > > print f(3) > > there is no problem: you can resolve during execution, and print an error > message (or whatever) then. But what about > > cond 1 (f(3) > 12) > > ? In similar C++ examples, such as > > cond 1 (A.f(3) > 12) > > you'll find that resolution problems are reported when the breakpoint is > hit, possibly long after the breakpoint is set. This is safe (the program > stops), but we felt it was somewhat annoying that one didn't notice the > problem earlier. > > We perform resolution in the obvious way, but that calls for > determining the static types of the arguments. While it is possible > to do so during parsing, it would mean partially rebuilding the > existing infrastructure that allows GDB to compute types and expression > values. We thought it would be easier to operate on the same prefix > form that is used for evaluation. Unfortunately, this happens only AFTER > the language-dependent parser returns. > > Paul Hilfinger > Ada Core Technologies, Inc. > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer