gdb: add support for Fortran's ASSUMED RANK arrays
authorrupothar <rupesh.potharla@amd.com>
Thu, 17 Mar 2022 18:56:23 +0000 (18:56 +0000)
committerAndrew Burgess <aburgess@redhat.com>
Sun, 3 Apr 2022 16:18:20 +0000 (17:18 +0100)
commitdf7a7bdd9766adebc6b117c31bc617d81c1efd43
tree36cf2204ceffa9b267a615088ef7bf5ae51c634b
parent1fb43cf75982f17c27ee0c72328de41750213689
gdb: add support for Fortran's ASSUMED RANK arrays

This patch adds a new dynamic property DYN_PROP_RANK, this property is
read from the DW_AT_rank attribute and stored within the type just
like other dynamic properties.

As arrays with dynamic ranks make use of a single
DW_TAG_generic_subrange to represent all ranks of the array, support
for this tag has been added to dwarf2/read.c.

The final piece of this puzzle is to add support in gdbtypes.c so that
we can resolve an array type with dynamic rank.  To do this the
existing resolve_dynamic_array_or_string function is split into two,
there's a new resolve_dynamic_array_or_string_1 core that is
responsible for resolving each rank of the array, while the now outer
resolve_dynamic_array_or_string is responsible for figuring out the
array rank (which might require resolving a dynamic property) and then
calling the inner core.

The resolve_dynamic_range function now takes a rank, which is passed
on to the dwarf expression evaluator.  This rank will only be used in
the case where the array itself has dynamic rank, but we now pass the
rank in all cases, this should be harmless if the rank is not needed.

The only small nit is that resolve_dynamic_type_internal actually
handles resolving dynamic ranges itself, which now obviously requires
us to pass a rank value.  But what rank value to use?  In the end I
just passed '1' through here as a sane default, my thinking is that if
we are in resolve_dynamic_type_internal to resolve a range, then the
range isn't part of an array with dynamic rank, and so the range
should actually be using the rank value at all.

An alternative approach would be to make the rank value a
gdb::optional, however, this ends up adding a bunch of complexity to
the code (e.g. having to conditionally build the array to pass to
dwarf2_evaluate_property, and handling the 'rank - 1' in
resolve_dynamic_array_or_string_1) so I haven't done that, but could,
if people think that would be a better approach.

Finally, support for assumed rank arrays was only fixed very recently
in gcc, so you'll need the latest gcc in order to run the tests for
this.

Here's an example test program:

  PROGRAM arank
    REAL :: a1(10)
    CALL sub1(a1)

  CONTAINS

    SUBROUTINE sub1(a)
      REAL :: a(..)
      PRINT *, RANK(a)
    END SUBROUTINE sub1
  END PROGRAM arank

Compiler Version:
gcc (GCC) 12.0.0 20211122 (experimental)

Compilation command:
gfortran assumedrank.f90 -gdwarf-5 -o assumedrank

Without Patch:

  gdb -q assumedrank
  Reading symbols from assumedrank...
  (gdb) break sub1
  Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
  (gdb) run
  Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank

  Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787
  /bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10
  10       PRINT *, RANK(a)
  (gdb) print RANK(a)
  'a' has unknown type; cast it to its declared type

With patch:

  gdb -q assumedrank
  Reading symbols from assumedrank...
  (gdb) break sub1
  Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
  (gdb) run
  Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank

  Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10
  10       PRINT *, RANK(a)
  (gdb) print RANK(a)
  $1 = 1
  (gdb) ptype a
  type = real(kind=4) (10)
  (gdb)

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
gdb/dwarf2/read.c
gdb/gdbtypes.c
gdb/gdbtypes.h
gdb/testsuite/gdb.fortran/assumedrank.exp [new file with mode: 0644]
gdb/testsuite/gdb.fortran/assumedrank.f90 [new file with mode: 0644]