Re: dynamic array's upper bound evaluated as address for AVR target

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pierre-Marie de Rodat wrote:

> Quick update: I started to dig into this. I still have a hard time 
> wrapping the current implementation in my mind[1] and thinking about 
> what we should do exactly:
> 
>    * Have different types for expressions and location lists (hence 
> potentially renaming existing code): looks like a big commit!
> 
>    * Introduce another entry point to evaluate dynamic properties as 
> expressions. Looks like a small change but a weaker design: how to 
> evaluate depends a property depends on the property, not the evaluation 
> context, so it would be great to keep types distinct.
> 
> I cannot make any commitment on a schedule to implement this, though.

It seems to me the easiest path to implement the change incrementally
might be:

a.) We currently have:

enum dynamic_prop_kind
{
  PROP_UNDEFINED, /* Not defined.  */
  PROP_CONST,     /* Constant.  */
  PROP_ADDR_OFFSET, /* Address offset.  */
  PROP_LOCEXPR,   /* Location expression.  */
  PROP_LOCLIST    /* Location list.  */
};

As a first step, add a value
  PROP_EXPR     /* DWARF expression.  */
to this list.

b.) Add code to dwarf2_evaluate_property / dwarf2_compile_property_to_c
to support PROP_EXPR.

This is a bit tricky since there is no real infrastructure to evaluate
DWARF expressions, as opposed to location expressions.  Note that the
existing routine dwarf_entry_parameter_to_value uses the trick to append
DW_OP_stack_value to the expression to force evaluation as a DWARF
expression instead of location.  The same could probably be done here.

c.) For the range-related dynamic properties, create PROP_EXPR property
nodes instead of PROP_LOC* property nodes.  This probably means splitting
the routine attr_to_dynamic_prop into two variants, one for locations
and one for dynamic properties.

-- At this point, everything should be functionally correct, the rest
   is simply cleanup ---

d.) Create some new common mechanism to handle DWARF locations

e.) Change the various places where DWARF locations are handled to use
this new common mechanism:
 - DW_AT_location      [ currently uses SYMBOL_COMPUTED_OPS ]
 - DW_AT_frame_base    [ currently uses SYMBOL_BLOCK_OPS ]
 - DW_AT_data_location [ currently uses dynamic_prop ]
 - DW_AT_static_link   [ currently uses dynamic_prop ]

f.) Finally, remove (now unused) support for PROP_LOCEXPR/PROP_LOCLIST
from the dynamic property code.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com