This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Add language-dependent post-parser
- From: Daniel Jacobowitz <drow at false dot org>
- To: Paul Hilfinger <hilfingr at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 30 Mar 2004 09:26:57 -0500
- Subject: Re: [RFA] Add language-dependent post-parser
- References: <20040330092413.2E716F281D@nile.gnat.com>
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 <Hilfinger@gnat.com>
>
> * 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