This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[00/11] Fortran dynamic arrays support


Hi,

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]