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

[Pierre-Marie de Rodat <derodat@adacore.com>]

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.

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.

-- 
Pierre-Marie de Rodat