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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: derodat at adacore dot com (Pierre-Marie de Rodat)
- Cc: brobecker at adacore dot com (Joel Brobecker), Pitchumani dot Sivanupandi at atmel dot com (Sivanupandi Pitchumani), gdb at sourceware dot org (gdb at sourceware dot org), andrew dot burgess at embecosm dot com (Andrew Burgess), tom at tromey dot com (tom at tromey dot com)
- Date: Fri, 23 Oct 2015 18:47:34 +0200 (CEST)
- Subject: Re: dynamic array's upper bound evaluated as address for AVR target
- Authentication-results: sourceware.org; auth=none
Pierre-Marie de Rodat wrote:
> Quick update: I started to dig into this. I still have a hard time
> wrapping the current implementation in my mind[1] and thinking about
> what we should do exactly:
>
> * Have different types for expressions and location lists (hence
> potentially renaming existing code): looks like a big commit!
>
> * Introduce another entry point to evaluate dynamic properties as
> expressions. Looks like a small change but a weaker design: how to
> evaluate depends a property depends on the property, not the evaluation
> context, so it would be great to keep types distinct.
>
> I cannot make any commitment on a schedule to implement this, though.
It seems to me the easiest path to implement the change incrementally
might be:
a.) We currently have:
enum dynamic_prop_kind
{
PROP_UNDEFINED, /* Not defined. */
PROP_CONST, /* Constant. */
PROP_ADDR_OFFSET, /* Address offset. */
PROP_LOCEXPR, /* Location expression. */
PROP_LOCLIST /* Location list. */
};
As a first step, add a value
PROP_EXPR /* DWARF expression. */
to this list.
b.) Add code to dwarf2_evaluate_property / dwarf2_compile_property_to_c
to support PROP_EXPR.
This is a bit tricky since there is no real infrastructure to evaluate
DWARF expressions, as opposed to location expressions. Note that the
existing routine dwarf_entry_parameter_to_value uses the trick to append
DW_OP_stack_value to the expression to force evaluation as a DWARF
expression instead of location. The same could probably be done here.
c.) For the range-related dynamic properties, create PROP_EXPR property
nodes instead of PROP_LOC* property nodes. This probably means splitting
the routine attr_to_dynamic_prop into two variants, one for locations
and one for dynamic properties.
-- At this point, everything should be functionally correct, the rest
is simply cleanup ---
d.) Create some new common mechanism to handle DWARF locations
e.) Change the various places where DWARF locations are handled to use
this new common mechanism:
- DW_AT_location [ currently uses SYMBOL_COMPUTED_OPS ]
- DW_AT_frame_base [ currently uses SYMBOL_BLOCK_OPS ]
- DW_AT_data_location [ currently uses dynamic_prop ]
- DW_AT_static_link [ currently uses dynamic_prop ]
f.) Finally, remove (now unused) support for PROP_LOCEXPR/PROP_LOCLIST
from the dynamic property code.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com