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

> -----Original Message-----
> From: Pierre-Marie de Rodat [mailto:[email protected]]
> Sent: 13 October 2015 20:14
> To: Sivanupandi, Pitchumani; [email protected]
> Cc: Andrew Burgess; [email protected]; [email protected]
> Subject: Re: dynamic array's upper bound evaluated as address for AVR target
> 
> Pitchumani,
> 
> (chiming in because I’ve worked a bit on DWARF expressions in GDB, but
> disclaimer: I’m not a maintainer ;-))
> 
> On 10/13/2015 11:07 AM, Sivanupandi, Pitchumani wrote:
> > Why is that location expression treated as DWARF_VALUE_MEMORY by default?
> > Can gdb detect if location expression for literal value (e.g. array
> > bounds) or not?
> 
> struct dwarf_expr_context::location is relevant only when evaluating DWARF
> expressions which are location descriptions. These descriptions generally
> compute addresses for objects but this “location” field makes it possible to
> describe objects that are not in memory (for instance in registers or
> several pieces in different places).
> 
> Anyway in the case you expose, the DWARF expressions compute bounds (i.e.
> scalar values) and thus this field is not relevant[1].
> 
> I was not aware of this hook (integer_to_address) and I could not find
> relevant documentation to learn about what it means, in what specific cases
> it should be used/avoided and why it exists in the first place (not being
> familiar with AVR neither, I don't understand what the corresponding code in
> avr-tdep.c does), so the following is speculation.

Target hook for integer_to_address does some manipulation on the given value.
In AVR target, it adds SRAM memory mask to the value to make that SRAM address.

> dwarf2_locexpr_baton_eval evaluates a DWARF expression assuming it computes
> the address of an object[1] and thus ends up invoking this hook. So my
> understanding is that either we should not call dwarf2_locexpr_baton_eval
> when evaluating things that are not locations (such as subrange bounds),
> either we should adapt dwarf2_locexpr_baton_eval to accept a new parameter
> telling wether the caller wants an address or a scalar.
> 
> Thoughts?
> 
> [1] This makes me feel like the handling of everything that is not
> DWARF_VALUE MEMORY in this function is dead (and incorrect) code: we should
> not get anything else in this context. I checked what happens when
> evaluating expressions in a GDB session:
> dwarf2_evaluate_loc_desc_full is called to get the location of objects, not
> dwarf2_locexpr_baton_eval. I tried to remove stack/register/literal handling
> and had no testsuite regression.

Function dwarf2_locexpr_baton_eval is called by dwarf2_evaluate_property for
location expression (from resolve_dynamic_range. i.e. to resolve bounds of 
dynamic array e.g. int int_vla[n] where n is function parameter).

Regards,
Pitchumani