Re: [PATCH 15/30] Add as_lval argument to expression evaluator

[Zoran Zaric via Gdb-patches <gdb-patches@sourceware.org>]

> 
> Zoran> There are cases where the result of the expression evaluation is
> Zoran> expected to be in a form of a value and not location description.
> 
> Zoran> One place that has this requirement is dwarf_entry_parameter_to_value
> Zoran> function, but more are expected in the future. Until now, this
> Zoran> requirement was fulfilled by extending the evaluated expression with
> Zoran> a DW_OP_stack_value operation at the end.
> 
> Zoran> New implementation, introduces a new evaluation argument instead.
> 
> I like this idea.
> While reading this, though, I was wondering if the new parameter ought
> to be given to the dwarf_expr_context constructor, rather than passed to
> the evaluation method.
> 
> Tom
> 

Thank you Tom.

Originally, I had an idea to have one persistent evaluator object per 
architecture that could be called to evaluate a given expression at any 
time.

In this scenario the as_lval information needs to be an evaluation call 
argument because it could change from evaluation to evaluation.

People didn't seem to like the idea of persistent evaluator so I guess 
many more arguments (if not all) could be just moved to the constructor.

In the later patches, the whole dwarf_expr_context class is hidden in 
the expr.c file and we end up with just one dwarf2_eval_exp function 
(which can be renamed to dwarf2_evaluate) that internally creates the 
evaluator object and calls the evaluation.

In that sense, we can move most of the evaluation arguments to be a 
constructor arguments and just leave the expression stream and result 
types as evaluation method arguments.

If people really feel that there is no need for multiple calls to the 
same evaluator object in the future, I will be happy to change it in the 
next patch series.

Zoran