Re: Variable Length Arrays (VLA) proposal

Jan Kratochvil
2013-07-02T19:21:06Z

On Tue, 02 Jul 2013 15:37:12 +0200, Jan Kratochvil wrote:
> > (2)
> > Type normalization:
> >
> > This proposal is similar to Jan's approach [1] in transforming dynamic values
> > of attributes into static ones:
> >
> > 1) resolve all dynamic attributes
> > 2) create a copy of the type and assign the resolved attributes from step 1)
> >
> > This proposal doesn't require to change check_typdef completely nor changing,
> > the TYPE_* macros, which makes this solution very isolated and lean.
> > Instead of hijacking check_typedef we hook into value_type() to normalize the
> > type. Since inferior types depend on a context - namely an address - to be
> > resolvable this seems a good place to hook into. In addition all expression
> > evaluations are routed via parse_and_eval() which returns a value, which may be
> > associated with an address. Also the TYPE_* macros in gdbtypes.h could be left
> > as-is. As a side effect gdb is now constantly creating types during the
> > normalization process and will increase the memory consumption constantly as
> > well. To avoid this behavior a garbage collector would be needed, which frees
> > the memory again when required. This could be done for example when GDB returns
> > to its main loop. Nevertheless, such a garbage collector can result in a
> > performance overhead, which is expected to be very small.
>
> I find this proposal interesting as hooking into value_type may be the right
> spot where one still has the address for DW_OP_push_object_address and where
> one can create appropriate static type. Current archer-jankratochvil-vla
> really usually calls object_address_set() close to value_type() anyway.
> This way one can avoid the difficulty of one global object address variable in
> archer-jankratochvil-vla when dealing with multiple variables at once.
>
> Implementation may not be so simple as for example
> dwarf2_evaluate_loc_desc_full case DWARF_VALUE_MEMORY sets value address
> added with its element offset which is wrong when one deals with
> DW_AT_push_object_address. In general in GDB there is value_address,
> value_raw_address, value_embedded_offset and value_pointed_to_offset which may
> the value address more difficult to get and set.
[...]
> One needs to be careful about item (1) of my "plan": val_print / c_val_print
> / LA_VAL_PRINT passing address and type passed separately. But it may work.
> Current archer-jankratochvil-vla has some hack for it in pascal_val_print;
> FYI pascal (fpc) needs similar dynamic types for its strings.

One issue is that value_type() returns even typedefs. But the dynamic types
needing to be converted to static form may be hidden after the typedefs.
That should be still easy.

If you have TYPE_CODE_ARRAY -> TYPE_CODE_STRUCT ->
-> one of the fields dynamic TYPE_CODE_ARRAY then you cannot make the inner
TYPE_CODE_ARRAY static but LA_VAL_PRINT will access it without new
value_type() as LA_VAL_PRINT already passes around separate type and separate
address. You cannot make the inner TYPE_CODE_ARRAY static apparently because
the type differs according to which outer TYPE_CODE_ARRAY element you access.

This is why I was thinking getting rid of things like LA_VAL_PRINT (converting
them to some form of LA_VALUE_PRINT, my item (5)) first may make the VLA task
easier.

Regards,
Jan