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

Joel Brobecker
2014-05-08T21:09:19Z

> 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