Re: Variable Length Arrays (VLA) proposal

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