This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Variable Length Arrays (VLA) proposal
- From: "Agovic, Sanimir" <sanimir dot agovic at intel dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>, "Boell, Keven" <keven dot boell at intel dot com>, "Weinmann, Christoph T" <christoph dot t dot weinmann at intel dot com>, "Chris January (chris dot january at allinea dot com)" <chris dot january at allinea dot com>, "Joel Brobecker (brobecker at adacore dot com)" <brobecker at adacore dot com>
- Date: Thu, 4 Jul 2013 12:16:45 +0000
- Subject: RE: Variable Length Arrays (VLA) proposal
- References: <0377C58828D86C4588AEEC42FC3B85A7176288F9 at IRSMSX105 dot ger dot corp dot intel dot com> <20130702133712 dot GA17311 at host2 dot jankratochvil dot net>
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