RE: Variable Length Arrays (VLA) proposal

Hello Jan,

thanks for your feedback.

> On Fri, 28 Jun 2013 15:01:25 +0200, Agovic, Sanimir wrote:
> > We've created three proposals, how VLA support can be added to FSF GDB.
> 
> FYI this plan is dealing various ways only with item (1) of my "plan"
> 	plan: VLA (Variable Length Arrays) and Fortran dynamic types
> 	http://sourceware.org/ml/gdb/2012-11/msg00094.html
>
Tackling item (1) first is rather a ration decision to get started and to gain
some practical experience on the gdb type system. We will have a closer look 
on the remaining items on the go, especially on the check_typedef problem.

> > (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 your proposal (2) avoids fixing the fragile check_typedef usage but
> I understand that is a different bug from the Fortran VLA-types bug.
Proposal (3) deals with some side effects present in check_typedef, we may
combine the proposals and fix the remaining issues until check_typedef 
gets obsolete.

> 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.
> 
Thanks for pointing out Pascal. Now we have Fortran, C, ADA, and Pascal on our radar.

> > (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
> >     - struct static_type
> >     - struct dynamic type
> >     - struct typedef_type
> 
> This seems to me as an implementation variant of the proposal (1).  The
> current inferior type system is horrible but I did not consider its
> refactorization meaningful before GDB starts to use C++; which currently does
> not seem to happen soon.
>
Imho we should consider (3) as a viable option independent of C++ usage.
I`m afraid that the discussion about pro/con C++ is going to harm GDB 
development. However, we may discuss the benefit of a transition to C++
in the _context_ of the gdb type system during cauldron2013 (BoF) and
on the ML.

 -Sanimir

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052