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: Chris January <chris dot january at allinea 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>
- Date: Thu, 4 Jul 2013 11:49:22 +0000
- Subject: RE: Variable Length Arrays (VLA) proposal
- References: <0377C58828D86C4588AEEC42FC3B85A7176288F9 at IRSMSX105 dot ger dot corp dot intel dot com> <1372434039 dot 2950 dot 12 dot camel at gumtree> <0377C58828D86C4588AEEC42FC3B85A71762A7F2 at IRSMSX105 dot ger dot corp dot intel dot com> <1372929205 dot 2796 dot 18 dot camel at gumtree>
> > Breakpoint 1, test () at vla.f90:4
> > 4 ALLOCATE(vla (3, 4, 5))
> > $1 = <not allocated>
> > type = integer(kind=4), ALLOCATABLE (0:1,0:1,0:1)
>
> This highlights another issues implementing VLA. When printing a type
> (e.g. in f-typeprint.c) you don't have the value of the variable and
> therefore you can't evaluate the DW_AT_lower_bound, DW_AT_upper_bound,
> DW_AT_allocated, etc. since they usually uses DW_OP_push_object_address
> and we don't have the value address in f_type_print and friends. So to
> print reliably print type type of an expression GDB actually needs to
> evaluate it, something it hasn't needed to do before.
Afaik gdb does a combination of:
const char * exp = [...]
struct expression *expr = parse_expression (exp);
struct value *val = evaluate_type (expr);
[...]
for whatis/ptype therefore we should be fine as we have a value in place.
-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