This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: dynamic array's upper bound evaluated as address for AVR target
- From: "Sivanupandi, Pitchumani" <Pitchumani dot Sivanupandi at atmel dot com>
- To: Pierre-Marie de Rodat <derodat at adacore dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Cc: Andrew Burgess <andrew dot burgess at embecosm dot com>, "tom at tromey dot com" <tom at tromey dot com>, "uweigand at de dot ibm dot com" <uweigand at de dot ibm dot com>
- Date: Wed, 14 Oct 2015 06:32:43 +0000
- Subject: RE: dynamic array's upper bound evaluated as address for AVR target
- Authentication-results: sourceware.org; auth=none
- References: <CAC140656783604CABA6AE60C2A6D5A4A2ED0DE4 at penmbx01> <561D18AD dot 6080701 at adacore dot com>
> -----Original Message-----
> From: Pierre-Marie de Rodat [mailto:derodat@adacore.com]
> Sent: 13 October 2015 20:14
> To: Sivanupandi, Pitchumani; gdb@sourceware.org
> Cc: Andrew Burgess; tom@tromey.com; uweigand@de.ibm.com
> 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