Add valaddr support in dynamic property resolution.

Add valaddr support in dynamic property resolution.

This is the second part of enhancing the debugger to print the value
of arrays of records whose size is variable when only standard DWARF
info is available (no GNAT encoding). For instance:

   subtype Small_Type is Integer range 0 .. 10;
   type Record_Type (I : Small_Type := 0) is record
      S : String (1 .. I);
   end record;
   type Array_Type is array (Integer range <>) of Record_Type;

   A1 : Array_Type := (1 => (I => 0, S => <>),
                       2 => (I => 1, S => "A"),
                       3 => (I => 2, S => "AB"));

Currently, GDB prints the following output:

        (gdb) p a1
        $1 = (

The error happens while the ada-valprint module is trying to print
the value of an element of our array. Because of the fact that
the array's element (type Record_Type) has a variant size, the DWARF
info for our array provide the array's stride:

     <1><749>: Abbrev Number: 10 (DW_TAG_array_type)
        <74a>   DW_AT_name        : (indirect string, offset: 0xb6d): pck__T18s
        <74e>   DW_AT_byte_stride : 16
        <74f>   DW_AT_type        : <0x6ea>

And because our array has a stride, ada-valprint treats it the same
way as packed arrays (see ada-valprint.c::ada_val_print_array):

  if (TYPE_FIELD_BITSIZE (type, 0) > 0)
    val_print_packed_array_elements (type, valaddr, offset_aligned,
                                     0, stream, recurse,
                                     original_value, options);

The first thing that we should notice in the call above is that
the "valaddr" buffer and the associated offset (OFFSET_ALIGNED)
is passed, but that the corresponding array's address is not.
This can be explained by looking inside val_print_packed_array_elements,
where we see that the function unpacks each element of our array from
the buffer alone (ada_value_primitive_packed_val), and then prints
the resulting artificial value instead:

      v0 = ada_value_primitive_packed_val (NULL, valaddr + offset,
                                           (i0 * bitsize) / HOST_CHAR_BIT,
                                           (i0 * bitsize) % HOST_CHAR_BIT,
                                           bitsize, elttype);

      [...]
              val_print (elttype, value_contents_for_printing (v0),
                         value_embedded_offset (v0), 0, stream,
                         recurse + 1, v0, &opts, current_language);

Of particular interest, here, is the fact that we call val_print
with a null address, which is OK, since we're providing a buffer
instead (value_contents_for_printing). Also, providing an address
might not always possible, since packing could place elements at
boundaries that are not byte-aligned.

Things go south when val_print tries to see if there is a pretty-printer
that could be applied. In particular, one of the first things that
the Python pretty-printer does is to create a value using our buffer,
and the given address, which in this case is null (see call to
value_from_contents_and_address in gdbpy_apply_val_pretty_printer).

value_from_contents_and_address, in turn immediately tries to resolve
the type, using the given address, which is null. But, because our
array element is a record containing an array whose bound is the value
of one of its elements (the "s" component), the debugging info for
the array's upper bound is a reference...

 <3><71a>: Abbrev Number: 7 (DW_TAG_subrange_type)
    <71b>   DW_AT_type        : <0x724>
    <71f>   DW_AT_upper_bound : <0x703>

... to component "i" of our record...

 <2><703>: Abbrev Number: 5 (DW_TAG_member)
    <704>   DW_AT_name        : i
    <706>   DW_AT_decl_file   : 2
    <707>   DW_AT_decl_line   : 6
    <708>   DW_AT_type        : <0x6d1>
    <70c>   DW_AT_data_member_location: 0

... where that component is located at offset 0 of the start
of the record. dwarf2_evaluate_property correctly determines
the offset where to load the value of the bound from, but then
tries to read that value from inferior memory using the address
that was given, which is null. See case PROP_ADDR_OFFSET in
dwarf2_evaluate_property:

        val = value_at (baton->offset_info.type,
                        pinfo->addr + baton->offset_info.offset);

This triggers a memory error, which then causes the printing to terminate.

Since there are going to be situations where providing an address
alone is not going to be sufficient (packed arrays where array elements
are not stored at byte boundaries), this patch fixes the issue by
enhancing the type resolution to take both address and data. This
follows the same principle as the val_print module, where both
address and buffer ("valaddr") can be passed as arguments. If the data
has already been fetched from inferior memory (or provided by the
debugging info in some form -- Eg a constant), then use that data
instead of reading it from inferior memory.

Note that this should also be a good step towards being able to handle
dynamic types whose value is stored outside of inferior memory
(Eg: in a register).

With this patch, GDB isn't able to print all of A1, but does perform
a little better:

    (gdb) p a1
    $1 = ((i => 0, s => , (i => 1, s => , (i => 2, s => )

There is another issue which is independent of this one, and will
therefore be patched separately.

gdb/ChangeLog:

        * dwarf2loc.h (struct property_addr_info): Add "valaddr" field.
        * dwarf2loc.c (dwarf2_evaluate_property): Add handling of
        pinfo->valaddr.
        * gdbtypes.h (resolve_dynamic_type): Add "valaddr" parameter.
        * gdbtypes.c (resolve_dynamic_struct): Set pinfo.valaddr.
        (resolve_dynamic_type_internal): Set pinfo.valaddr.
        Add handling of addr_stack->valaddr.
        (resolve_dynamic_type): Add "valaddr" parameter.
        Set pinfo.valaddr field.
        * ada-lang.c (ada_discrete_type_high_bound): Update call to
        resolve_dynamic_type.
        (ada_discrete_type_low_bound): Likewise.
        * findvar.c (default_read_var_value): Likewise.
        * value.c (value_from_contents_and_address): Likewise.