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: Pierre-Marie de Rodat <derodat at adacore dot com>
- To: "Sivanupandi, Pitchumani" <Pitchumani dot Sivanupandi at atmel 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: Tue, 13 Oct 2015 16:43:57 +0200
- Subject: Re: dynamic array's upper bound evaluated as address for AVR target
- Authentication-results: sourceware.org; auth=none
- References: <CAC140656783604CABA6AE60C2A6D5A4A2ED0DE4 at penmbx01>
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