Variable Length Arrays (VLA) proposal

[Jan Kratochvil]

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