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: Wed, 14 Oct 2015 08:54:29 +0200
- 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> <CAC140656783604CABA6AE60C2A6D5A4A2ED2398 at penmbx01>
On 10/14/2015 08:32 AM, Sivanupandi, Pitchumani wrote:
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.
This is what I observed, but I wonder: why do we need this in the first
place? In what situation do we have an integer on which we need to apply
a mask to get an address (i.e. from where does this integer come?).
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).
Then maybe we should add this expect_address parameter to both
dwarf2_evaluate_property and dwarf2_locexpr_baton_evalâ
--
Pierre-Marie de Rodat