Re: Variable Length Arrays (VLA) proposal

Jan Kratochvil
2013-08-04T19:02:10Z

On Fri, 28 Jun 2013 15:01:25 +0200, Agovic, Sanimir wrote:
> (3)
> Split struct type:
>
> The idea behind this proposal is to reflect the difference of types (dynamic/
> static attributes) in the type system used in GDB. At the moment we consider the
> following types:
>
> - struct type
> Serves as a base. Certain properties are exposed using function pointers
> instead of raw attribute access e.g. length, bounds.
>
> - struct static_type
> Reassembles the functionality of the current struct type. It is used for
> types with statically values of attributes.
>
> - struct dynamic type
> Allows to express the dynamic values of attributes. Computation of length
> and bounds might be done lazily.
>
> - struct typedef_type
> A simple proxy type. Calls to length and bounds are forwarded to the
> underlying type.

I think you would need also some:
- struct opaque_type

to resolve TYPE_IS_OPAQUE/TYPE_STUB/TYPE_TARGET_STUB types.

> Proposal (3) will make the type system of GDB more flexible, as differentiating
> between static and dynamic types. Also it will calculate dynamic attributes when
> they will be requested by the caller.

If you want to do the calculation any time when TYPE_ARRAY_UPPER_BOUND_VALUE
is called then you do not have the object address available - where will you
get it? The global pointer archer-jankratochvil-vla is using is really not
acceptable.

> An implementation details which is left out is whether one would implement it in
> a OO style similar to breakpoint_ops.

In part similar to breakpoint_ops but also similar to SYMBOL_IMPL - to save
the 8 bytes of a pointer - as struct type (main_type) should be very small.
Due to expansion of whole CUs (Compilation Units) together with CU
interdependencies one gets tons of struct type (main_type) instances
with C++ inferiors.

> Also
> extensions and future requirements could be better addressed by simply
> refactoring struct members into function pointers. The check_type function could
> be shortened, as function pointers will do the dynamic calculation work,

I believe you are now talking more about full struct type/main_type rework,
aren't you? It could be better to provide data definition samples.
Personally I do not think it is worth to start the struct type/main_type
rework in some pseudo-C++, before real C++ gets deployed.

> and in future steps completely removed by adding a function peel(), which
> would recursively peel of any typedefs. This change would be rather large
> and would affect many areas of GDB, like proposal (1).

I do not understand much this paragraph and I find it mostly off-topic here.
Callers of check_typedef currently expect all the typedefs get stripped so
I do not see who would be the callers for peel().

> The implementation of proposal (2) would be very isolated and simple, but will
> leave the static attributes in struct type, which are actually dynamic.

After all I find the (2) proposal the most one feasible, hooking into
value_type() together with some cleanups
like my-proposal (5) LA_VAL_PRINT->LA_VALUE_PRINT should make it working.

> However, also this change will be large as lots of GDB code need to be
> touched but it is the preferred proposal from our side.

As I see we found disagreement whether to go the (2) or (3) way I have placed
some question above which should clear it up what are your plans.

Thanks,
Jan