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

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

Pierre-Marie de Rodat wrote:
> On 10/14/2015 09:54 AM, Sivanupandi, Pitchumani wrote:
> >> Then maybe we should add this expect_address parameter to both
> >> dwarf2_evaluate_property and dwarf2_locexpr_baton_eval…
> >
> > Ok. I'll try it out.
> 
> Thank you! As I said previously, I’m not a maintainer: I added Joel as a 
> recipient since he’s both a maintainer and the original author of the 
> dwarf2 property mechanism.

I've just had a quick look at the "dwarf2 property" mechanism, and it seems
to me that our current implementation mixes up two different things.  We
currently use attr_to_dynamic_prop for three property types:

DW_AT_lower_bound
DW_AT_upper_bound
DW_AT_count
DW_AT_static_link
DW_AT_data_location

However, the DWARF standard describes the first three in a quite different
manner than the latter two.

For DW_AT_static_link, we have:

  If a subroutine or entry point is nested, it may have a DW_AT_static_link
  attribute, whose value is a location description that computes the frame
  base of the relevant instance of the subroutine that immediately encloses
  the subroutine or entry point.

For DW_AT_data_location, we have:

  The DW_AT_data_location attribute may be used with any type that provides
  one or more levels of hidden indirection and/or run-time parameters in its
  representation. Its value is a location description. The result of evaluating
  this description yields the location of the data for an object.

So those two are *location descriptions* that evaluate to an address.  They
should be treated just like DW_AT_frame_base is today, i.e. using the
dwarf2_loclist_baton/dwarf2_locexpr_baton mechanism.

On the other hand, for the first three attrbutes, the standard says:

  The subrange entry may have the attributes DW_AT_lower_bound and
  DW_AT_upper_bound to specify, respectively, the lower and upper bound
  values of the subrange. The DW_AT_upper_bound attribute may be replaced
  by a DW_AT_count attribute, whose value describes the number of elements
  in the subrange rather than the value of the last element. The value of
  each of these attributes is determined as described in Section 2.19.

Where section 2.19 reads:

  Some attributes that apply to types specify a property (such as the lower
  bound of an array) that is an integer value, where the value may be known
  during compilation or may be computed dynamically during execution.
  The value of these attributes is determined based on the class as follows:
  • For a constant, the value of the constant is the value of the attribute.
  • For a reference, the value is a reference to another entity which
    specifies the value of the attribute.
  • For an exprloc, the value is interpreted as a DWARF expression;
    evaluation of the expression yields the value of the attribute.

where the value may be a DWARF *expression*, but not a location description,
and it results in an integer, not an address.

Note that a plain DWARF expression can actually from a valid location
description (namely a simple memory location expression), but there are
many more options how a location description can look.

I think the current GDB "dynamic property" mechanism was probably intended
to capture what DWARF section 2.19 specifies, but due to its simultaneous
use for DW_AT_data_location and DW_AT_static_link, things got confused.

It would probably be best to clearly separate this out into two separate
mechanisms, one that precisely implements dynamic properties as defined
in section 2.19, and one that implements location descriptions.  (Note
that those mechanism should ideally then be used for some of the *other*
places where the DWARF standard also allows either a dynamic property or
a location description, but GDB doesn't accept them yet.)

This would then have the side effect that we could distinguish return
types: location descriptions always return an address, but section 2.19
dynamic attributes always return an integer.

Bye,
Ulrich

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