Re: [00/11] Fortran dynamic arrays support

[Jim Blandy <jimb@codesourcery.com>]

Hi, Jan.  I would be a natural reviewer for this, but I'll be on
vacation next week (it's the U.S. Thanksgiving holiday), so I, at
least, won't be able to review this promptly.

Jan Kratochvil <jan.kratochvil at redhat.com> writes:
> currently GDB cannot display allocated or associated (dynamic) Fortran arrays.
> Support for the DWARF annotation of these is still not commited in GCC SVN.
> GCC Bug:
> 	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
> Latest GCC 4.3 patch:
> 	http://people.redhat.com/jkratoch/rh364001/gcc22244-Z40d-jakub.patch
> Prebuilt Fortran testcase:
> 	http://people.redhat.com/jkratoch/rh364001/testcase-a5-jakub.tar.gz
> Jakub's mail (old):
> 	http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00612.html
>
> This patchset should also enable proper handling of C VLAs (Variable Length
> Arrays) but GCC-4.x does not emit any DWARF and the GCC-3.4 DWARF was IMO wrong
> for them.
>
> These GDB features are missing and get implemented by the patchset:
> * Dynamic array bounds.
> * DW_AT_*stride.
> * DW_AT_data_location.
> * DW_FORM_block* for DW_AT_lower_bound, DW_AT_upper_bound, DW_AT_*stride.
>
> Most of the support was intentionally limited only for the Fortran arrays where
> it is currently only produced by GCC.
>
> Patchset has incremental dependencies.  All stages are buildable but only the
> full patchset has been regression tested by the testsuite.
>
> Current output is:
> 	(gdb) ptype varx
> 	type = real*4 (0:-1,0:-1,0:-1)
> 	(gdb) p varx
> 	$1 = ()
> Patched output is:
> 	(gdb) ptype varx
> 	type = real*4 (6,5:15,17:28)
> 	(gdb) p varx
> 	$1 = (( ( 7, 6, 6, 6, 6, 6) ( 6, 6, 6, 6, 6, 6) ( 6, [cut ...]
>
> There is a design problem that GDB deals with the TYPE already without any
> relation to the original variable.  I tried to patch there a general
> TYPE->VARIABLE binding first but it is too intrusive for GDB as it makes the
> same abstract TYPE and VARIABLE-bound TYPE two different objects.  Current
> patchset provides another function parameter in the codepaths requiring it.
>
> Another design problem is that TYPE_LENGTH (and other macros) defined as
> `type->length' need to behave dynamically now (calculate DWARF expressions) but
> the same macro is currently used everywhere both as the setter (lval) and the
> getter.  Currently the getter call is replaced on (few) places where it was
> required for the Fortran arrays.
>
> I can expand there some of the compatibility wrapping functions if it gets
> otherwise accepted.
>
> This GCC Fortran <-> GDB patches were not tested against any 3rd part DWARF
> producers/consumers (which exist?).
>
>
> Regards,
> Jan