Re: [PATCH 2/2] handle VLA in a struct or union

[Joel Brobecker <brobecker@adacore.com>]

> However, before this goes in, I'd like to understand the oddity
> pointed out by a change in is_dynamic_type.  That is, this test:
> 
> 	      /* This can happen with Ada for reasons unknown.  */
> 	      && TYPE_FIELD_TYPE (type, i) != NULL
> 
> is needed to avoid a crash with the Ada "iwide.exp" test.  This type:
> 
>     (top-gdb) p real_type.main_type.name
>     $15 = 0x7ffff0354c6d "ada__tags__type_specific_data___XVE"
> 
> ... has a seemingly invalid field:
> 
>     (top-gdb) p real_type.main_type.nfields
>     $9 = 13
> [...]
>     (top-gdb) p real_type.main_type.flds_bnds.fields[12]
>     $12 = {
>       loc = {
> 	bitpos = 576,
> 	enumval = 576,
> 	physaddr = 576,
> 	physname = 0x240 <Address 0x240 out of bounds>,
> 	dwarf_block = 0x240
>       },
>       artificial = 0,
>       loc_kind = FIELD_LOC_KIND_BITPOS,
>       bitsize = 0,
>       type = 0x0,
>       name = 0x0
>     }
> 
> Joel, can you comment?  Thanks.

It's actually not the only testcase I see being impacted if I remove
the check. What happens is that we're in the middle of resolving
this very type (what we have been calling creating a fixed version
of the type). While doing so, we do...

    if (dval0 == NULL)
      {
        /* rtype's length is computed based on the run-time
           value of discriminants.  If the discriminants are not
           initialized, the type size may be completely bogus and
           GDB may fail to allocate a value for it.  So check the
           size first before creating the value.  */
        check_size (rtype);
        dval = value_from_contents_and_address (rtype, valaddr, address);
        rtype = value_type (dval);
      }

... where rtype is the resolved type being constructed, and therefore
a type that isn't completely consistent yet. the call to
value_from_contents_and_address eventually leads to the is_dynamic_type
call.

I think I need to review that code, as I do that a litte little
later in the function again. I'll send another update when I have
more info on this.

-- 
Joel