[PATCH 0/2][PR fortran/26373][PR fortran/22497] GDB support for Fortran extends feature

[PATCH 0/2][PR fortran/26373][PR fortran/22497] GDB support for Fortran extends feature

[Nils-Christian Kempke via Gdb-patches]

Hi,

please find attached 2 patches enabling GDB to deal with the
Fortran 2003 feature of type extension.

For ifx and ifort this patch addresses the above mentioned Bugzilla
bugs fully.  For gfortran (and flang - these are all I tried) the
bugs still somewhat exist but I'd not consider them to be on GDB side.

The problem when using gfortran (or flang) is, that the compilers
do not emit the respective DWARF tag for inheritance when the extends
feature is used.  Thus, GDB has no chance of actually knowing about
it. Assume the following scenario:

    type :: a
        real :: a_real
    end type a

    type, extends(a) :: b
    end type b

Now if we have

    type(b) :: obj

and compiled with gfortran or flang GDB is not able to directly resolve
a member access of the sort

    (gdb) obj%a_real
    There is no member named a_real.

since gfortran will not emit the DW_TAG_inheritance for b.  There is a
gcc bug gcc/49475 filed for this which is set as kfail in the respective
test in [PATCH (1/2)].

Any feedback is welcome!

Cheers,

Nils

Bernhard Heckel (2):
  gdb/fortran: add support for accessing fields of extended types
  gdb/fortran: print fortran extended types with ptype

 gdb/f-exp.y                                   |   7 +-
 gdb/f-lang.h                                  |  11 +
 gdb/f-typeprint.c                             |  24 ++-
 gdb/testsuite/gdb.fortran/oop_extend_type.exp | 190 ++++++++++++++++++
 gdb/testsuite/gdb.fortran/oop_extend_type.f90 |  69 +++++++
 gdb/valops.c                                  |   6 +
 6 files changed, 303 insertions(+), 4 deletions(-)
 create mode 100755 gdb/testsuite/gdb.fortran/oop_extend_type.exp
 create mode 100755 gdb/testsuite/gdb.fortran/oop_extend_type.f90

-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Nils-Christian Kempke via Gdb-patches]

From: Bernhard Heckel <bernhard.heckel@intel.com>

Fortran 2003 supports type extension.  This patch allows access
to inherited members by using their fully qualified name as described
in the Fortran standard.

In doing so the patch also fixes a bug in GDB when trying to access the
members of a base class in a derived class via the derived class' base
class member.

This patch fixes PR22497 and PR26373 on GDB side.

Using the example Fortran program from PR22497

program mvce
  implicit none

  type :: my_type
     integer :: my_int
  end type my_type

  type, extends(my_type) :: extended_type
  end type extended_type

  type(my_type) :: foo
  type(extended_type) :: bar

  foo%my_int = 0
  bar%my_int = 1

  print*, foo, bar

end program mvce

and running this with GDB and setting a BP at 17:

Before:
(gdb) p bar%my_type
A syntax error in expression, near `my_type'.
(gdb) p bar%my_int
There is no member named my_int.
(gdb) p bar%my_type%my_int
A syntax error in expression, near `my_type%my_int'.
(gdb) p bar
$1 = ( my_type = ( my_int = 1 ) )

After:
(gdb) p bar%my_type
$1 = ( my_int = 1 )
(gdb) p bar%my_int
$2 = 1                 # this line requires DW_TAG_inheritance to work
(gdb) p bar%my_type%my_int
$3 = 1
(gdb) p bar
$4 = ( my_type = ( my_int = 1 ) )

In the above example "p bar%my_int" requires the compiler to emit
information about the inheritance relationship between extended_type
and my_type which gfortran and flang currently do not de.  The
respective issue gcc/49475 has been put as kfail.

Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26373
     https://sourceware.org/bugzilla/show_bug.cgi?id=22497
---
 gdb/f-exp.y                                   |   7 +-
 gdb/testsuite/gdb.fortran/oop_extend_type.exp | 159 ++++++++++++++++++
 gdb/testsuite/gdb.fortran/oop_extend_type.f90 |  69 ++++++++
 gdb/valops.c                                  |   6 +
 4 files changed, 239 insertions(+), 2 deletions(-)
 create mode 100755 gdb/testsuite/gdb.fortran/oop_extend_type.exp
 create mode 100755 gdb/testsuite/gdb.fortran/oop_extend_type.f90

diff --git a/gdb/f-exp.y b/gdb/f-exp.y
index 42d3130bf8..a00e211b80 100644
--- a/gdb/f-exp.y
+++ b/gdb/f-exp.y
@@ -808,8 +808,11 @@ nonempty_typelist
 		}
 	;
 
-name	:	NAME
-		{  $$ = $1.stoken; }
+name
+	:	NAME
+		{ $$ = $1.stoken; }
+	|	TYPENAME
+		{ $$ = $1.stoken; }
 	;
 
 name_not_typename :	NAME
diff --git a/gdb/testsuite/gdb.fortran/oop_extend_type.exp b/gdb/testsuite/gdb.fortran/oop_extend_type.exp
new file mode 100755
index 0000000000..5d73e14a56
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/oop_extend_type.exp
@@ -0,0 +1,159 @@
+# Copyright 2016 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+standard_testfile ".f90"
+load_lib "fortran.exp"
+
+if { [skip_fortran_tests] } {
+    return -1
+}
+
+if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} \
+     {debug f90 quiet}] } {
+	 return -1
+}
+
+if ![fortran_runto_main] {
+    perror "could not run to main"
+    return -1
+}
+
+# Depending on the compiler being used, the type names can be printed differently.
+set real [fortran_real4]
+set logical [fortran_logical4]
+
+set line1 [gdb_get_line_number "! Before vla allocation"]
+gdb_breakpoint $line1
+gdb_continue_to_breakpoint "line1" ".*$srcfile:$line1.*"
+
+gdb_test "whatis wp_vla" "type = Type waypoint, allocatable \\(:\\)" \
+    "whatis wp_vla before allocation"
+
+set line2 [gdb_get_line_number "! After value assignment"]
+gdb_breakpoint $line2
+gdb_continue_to_breakpoint "line2" ".*$srcfile:$line2.*"
+
+# test print of wp
+set test "p wp%coo"
+gdb_test_multiple "$test" "$test" {
+    -re " = \\(1, 2, 1\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+gdb_test "p wp%point%coo" " = \\(1, 2, 1\\)"
+gdb_test "p wp%point" " = \\( coo = \\(1, 2, 1\\) \\)"
+gdb_test "p wp" " = \\( point = \\( coo = \\(1, 2, 1\\) \\), angle = 100 \\)"
+
+gdb_test "whatis wp" "type = Type waypoint"
+gdb_test "ptype wp" \
+  [multi_line "type = Type waypoint" \
+	      "    Type point :: point" \
+	      "    $real :: angle" \
+	      "End Type waypoint"]
+
+set test "ptype wp%coo"
+gdb_test_multiple "$test" "$test" {
+    -re "$real \\(3\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+gdb_test "ptype wp%point%coo" "$real \\(3\\)"
+
+# test print of fwp
+set test "p fwp%coo"
+gdb_test_multiple "$test" "$test" {
+    -re " = \\(1, 2, 2\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+gdb_test "p fwp%waypoint%point%coo" " = \\(1, 2, 2\\)"
+gdb_test "p fwp%waypoint%point" " = \\( coo = \\(1, 2, 2\\) \\)"
+gdb_test "p fwp%waypoint" \
+    " = \\( point = \\( coo = \\(1, 2, 2\\) \\), angle = 10 \\)"
+gdb_test "p fwp" \
+    " = \\( waypoint = \\( point = \\( coo = \\(1, 2, 2\\) \\), angle = 10 \\), is_fancy = \.TRUE\. \\)"
+
+set test "p fwp%angle"
+gdb_test_multiple "$test" "$test" {
+    -re " = 10\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named angle.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+
+gdb_test "whatis fwp" "type = Type fancywaypoint"
+gdb_test "ptype fwp" \
+  [multi_line "type = Type fancywaypoint" \
+	      "    Type waypoint :: waypoint" \
+	      "    $logical :: is_fancy" \
+	      "End Type fancywaypoint"]
+
+set test "ptype fwp%coo"
+gdb_test_multiple "$test" "$test" {
+    -re "$real \\(3\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+gdb_test "ptype fwp%waypoint%point%coo" "$real \\(3\\)"
+
+# test print of wp_vla
+set test "p wp_vla(1)%coo"
+gdb_test_multiple "$test" "$test" {
+    -re " = \\(10, 12, 10\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+
+gdb_test "p wp_vla(1)%point%coo" " = \\(10, 12, 10\\)"
+gdb_test "p wp_vla(1)%point" " = \\( coo = \\(10, 12, 10\\) \\)"
+gdb_test "p wp_vla(1)" " = \\( point = \\( coo = \\(10, 12, 10\\) \\), angle = 101 \\)"
+
+gdb_test "whatis wp_vla" "type = Type waypoint, allocatable \\(3\\)" \
+    "whatis wp_vla after allocation"
+
+gdb_test "ptype wp_vla" \
+  [multi_line "type = Type waypoint" \
+	      "    Type point :: point" \
+	      "    $real :: angle" \
+	      "End Type waypoint, allocatable \\(3\\)"]
+
+set test "ptype wp_vla(1)%coo"
+gdb_test_multiple "$test" "$test" {
+    -re "$real \\(3\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "There is no member named coo.\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
+
+gdb_test "ptype wp_vla(1)%point%coo" "$real \\(3\\)"
diff --git a/gdb/testsuite/gdb.fortran/oop_extend_type.f90 b/gdb/testsuite/gdb.fortran/oop_extend_type.f90
new file mode 100755
index 0000000000..dc91c45c60
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/oop_extend_type.f90
@@ -0,0 +1,69 @@
+! Copyright 2022 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 3 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+! Test fortran extends feature (also for chained extends).
+module testmod
+    implicit none
+    type :: point
+	real :: coo(3)
+    end type
+
+    type, extends(point) :: waypoint
+	real :: angle
+    end type
+
+    type, extends(waypoint) :: fancywaypoint
+	logical :: is_fancy
+    end type
+end module
+
+program testprog
+    use testmod
+    implicit none
+
+    logical l
+    type(waypoint) :: wp
+    type(fancywaypoint) :: fwp
+    type(waypoint), allocatable :: wp_vla(:)
+
+    l = .FALSE.
+    allocate(wp_vla(3)) ! Before vla allocation
+
+    l = allocated(wp_vla) ! After vla allocation
+
+    wp%angle = 100.00
+    wp%coo(:) = 1.00
+    wp%coo(2) = 2.00
+
+    fwp%is_fancy = .TRUE.
+    fwp%angle = 10.00
+    fwp%coo(:) = 2.00
+    fwp%coo(1) = 1.00
+
+    wp_vla(1)%angle = 101.00
+    wp_vla(1)%coo(:) = 10.00
+    wp_vla(1)%coo(2) = 12.00
+
+    wp_vla(2)%angle = 102.00
+    wp_vla(2)%coo(:) = 20.00
+    wp_vla(2)%coo(2) = 22.00
+
+    wp_vla(3)%angle = 103.00
+    wp_vla(3)%coo(:) = 30.00
+    wp_vla(3)%coo(2) = 32.00
+
+    print *, wp, wp_vla, fwp ! After value assignment
+
+end program
diff --git a/gdb/valops.c b/gdb/valops.c
index e091c445e7..65fad4d5e6 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
       if (v)
 	return v;
 
+      /* Fortran: If it is not a field it is the type name of an inherited
+	 structure.  */
+      v = search_struct_field (name, *argp, t, 1);
+      if (v)
+	return v;
+
       /* C++: If it was not found as a data field, then try to
 	 return it as a pointer to a method.  */
       v = search_struct_method (name, argp, args, 0,
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH 2/2] gdb/fortran: print fortran extended types with ptype

[Nils-Christian Kempke via Gdb-patches]

From: Bernhard Heckel <bernhard.heckel@intel.com>

Add the print of the base-class of an extended type to the output of
ptype.  This requires the Fortran compiler to emit DW_AT_inheritance
for the extended type.

Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
 gdb/f-lang.h                                  | 11 ++++
 gdb/f-typeprint.c                             | 24 ++++++-
 gdb/testsuite/gdb.fortran/oop_extend_type.exp | 65 ++++++++++++++-----
 3 files changed, 81 insertions(+), 19 deletions(-)

diff --git a/gdb/f-lang.h b/gdb/f-lang.h
index 26b2c09309..14ab8ce245 100644
--- a/gdb/f-lang.h
+++ b/gdb/f-lang.h
@@ -260,6 +260,17 @@ class f_language : public language_defn
 				    int arrayprint_recurse_level,
 				    bool print_rank_only) const;
 
+  /* If TYPE is an extended type, then print out derivation information.
+
+     A typical output could look like this:
+     "Type, extends(point) :: waypoint"
+     "    Type point :: point"
+     "    real(kind=4) :: angle"
+     "End Type waypoint".  */
+
+  void f_type_print_derivation_info (struct type *type,
+				     struct ui_file *stream) const;
+
   /* Print the name of the type (or the ultimate pointer target, function
      value or array element), or the description of a structure or union.
 
diff --git a/gdb/f-typeprint.c b/gdb/f-typeprint.c
index a633e47b2d..1761a38e94 100644
--- a/gdb/f-typeprint.c
+++ b/gdb/f-typeprint.c
@@ -282,6 +282,19 @@ f_language::f_type_print_varspec_suffix (struct type *type,
 
 /* See f-lang.h.  */
 
+void
+f_language::f_type_print_derivation_info (struct type *type,
+					  struct ui_file *stream) const
+{
+  const int i = 0;  // Fortran doesn't support multiple inheritance.
+
+  if (TYPE_N_BASECLASSES (type) > 0)
+    fprintf_filtered (stream, ", extends(%s) ::",
+		      TYPE_BASECLASS (type, i)->name ());
+}
+
+/* See f-lang.h.  */
+
 void
 f_language::f_type_print_base (struct type *type, struct ui_file *stream,
 			       int show, int level) const
@@ -392,10 +405,17 @@ f_language::f_type_print_base (struct type *type, struct ui_file *stream,
     case TYPE_CODE_STRUCT:
     case TYPE_CODE_UNION:
       if (type->code () == TYPE_CODE_UNION)
-	fprintf_filtered (stream, "%*sType, C_Union :: ", level, "");
+	fprintf_filtered (stream, "%*sType, C_Union ::", level, "");
       else
-	fprintf_filtered (stream, "%*sType ", level, "");
+	fprintf_filtered (stream, "%*sType", level, "");
+
+      if (show > 0)
+	f_type_print_derivation_info (type, stream);
+
+      fputs_filtered (" ", stream);
+
       fputs_filtered (type->name (), stream);
+
       /* According to the definition,
 	 we only print structure elements in case show > 0.  */
       if (show > 0)
diff --git a/gdb/testsuite/gdb.fortran/oop_extend_type.exp b/gdb/testsuite/gdb.fortran/oop_extend_type.exp
index 5d73e14a56..3b4e6cac3a 100755
--- a/gdb/testsuite/gdb.fortran/oop_extend_type.exp
+++ b/gdb/testsuite/gdb.fortran/oop_extend_type.exp
@@ -60,12 +60,24 @@ gdb_test "p wp%point" " = \\( coo = \\(1, 2, 1\\) \\)"
 gdb_test "p wp" " = \\( point = \\( coo = \\(1, 2, 1\\) \\), angle = 100 \\)"
 
 gdb_test "whatis wp" "type = Type waypoint"
-gdb_test "ptype wp" \
-  [multi_line "type = Type waypoint" \
-	      "    Type point :: point" \
-	      "    $real :: angle" \
-	      "End Type waypoint"]
-
+set output_pass_wp [multi_line "type = Type, extends\\(point\\) :: waypoint" \
+			       "    Type point :: point" \
+			       "    $real :: angle" \
+			       "End Type waypoint(, allocatable)?"]
+set output_kfail_wp [multi_line "type = Type waypoint" \
+			        "    Type point :: point" \
+			        "    $real :: angle" \
+			        "End Type waypoint(, allocatable)?"]
+
+set test "ptype wp"
+gdb_test_multiple "$test" "$test" {
+    -re "$output_pass_wp\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "$output_kfail_wp\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
 set test "ptype wp%coo"
 gdb_test_multiple "$test" "$test" {
     -re "$real \\(3\\)\r\n$gdb_prompt $" {
@@ -105,11 +117,27 @@ gdb_test_multiple "$test" "$test" {
 }
 
 gdb_test "whatis fwp" "type = Type fancywaypoint"
-gdb_test "ptype fwp" \
-  [multi_line "type = Type fancywaypoint" \
-	      "    Type waypoint :: waypoint" \
-	      "    $logical :: is_fancy" \
-	      "End Type fancywaypoint"]
+set test "ptype fwp"
+
+set output_pass_fwp \
+    [multi_line "type = Type, extends\\(waypoint\\) :: fancywaypoint" \
+		"    Type waypoint :: waypoint" \
+		"    $logical :: is_fancy" \
+		"End Type fancywaypoint"]
+set output_kfail_fwp \
+    [multi_line "type = Type fancywaypoint" \
+		"    Type waypoint :: waypoint" \
+		"    $logical :: is_fancy" \
+		"End Type fancywaypoint"]
+
+gdb_test_multiple "$test" "$test" {
+    -re "$output_pass_fwp\r\n$gdb_prompt $" {
+	pass  "$test"
+    }
+    -re "$output_kfail_fwp\r\n$gdb_prompt $" {
+	kfail "gcc/49475" "$test"
+    }
+}
 
 set test "ptype fwp%coo"
 gdb_test_multiple "$test" "$test" {
@@ -140,12 +168,15 @@ gdb_test "p wp_vla(1)" " = \\( point = \\( coo = \\(10, 12, 10\\) \\), angle = 1
 gdb_test "whatis wp_vla" "type = Type waypoint, allocatable \\(3\\)" \
     "whatis wp_vla after allocation"
 
-gdb_test "ptype wp_vla" \
-  [multi_line "type = Type waypoint" \
-	      "    Type point :: point" \
-	      "    $real :: angle" \
-	      "End Type waypoint, allocatable \\(3\\)"]
-
+set test "ptype wp_vla"
+gdb_test_multiple "$test" "$test" {
+    -re "$output_pass_wp \\(3\\)\r\n$gdb_prompt $" {
+      pass "$test"
+    }
+    -re "$output_kfail_wp \\(3\\)\r\n$gdb_prompt $" {
+      kfail "gcc/49475" "$test"
+    }
+}
 set test "ptype wp_vla(1)%coo"
 gdb_test_multiple "$test" "$test" {
     -re "$real \\(3\\)\r\n$gdb_prompt $" {
-- 
2.25.1

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Tom Tromey]

>>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> writes:

>> From: Bernhard Heckel <bernhard.heckel@intel.com>
>> Fortran 2003 supports type extension.  This patch allows access
>> to inherited members by using their fully qualified name as described
>> in the Fortran standard.

Thanks for the patch.

>> In doing so the patch also fixes a bug in GDB when trying to access the
>> members of a base class in a derived class via the derived class' base
>> class member.

>> @@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
>>        if (v)
>>  	return v;
 
>> +      /* Fortran: If it is not a field it is the type name of an inherited
>> +	 structure.  */
>> +      v = search_struct_field (name, *argp, t, 1);
>> +      if (v)
>> +	return v;

Putting this here makes me wonder if it's possible to construct test
cases in other languages that would work without this patch and then
fail with it.

I'm not sure what the options are though.  Doing the work elsewhere, say
in a custom Fortran expression operation, might make the Python API
harder to work with.  Maybe having value_struct_elt check
current_language would work... that's also quite ugly but other value
operations are doing that.

Or maybe my fears are overblown.

Any thoughts on this?

Tom

Re: [PATCH 2/2] gdb/fortran: print fortran extended types with ptype

[Tom Tromey]

>>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> writes:

>> From: Bernhard Heckel <bernhard.heckel@intel.com>
>> Add the print of the base-class of an extended type to the output of
>> ptype.  This requires the Fortran compiler to emit DW_AT_inheritance
>> for the extended type.

>> Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

Thank you.  This looks ok to me.

Tom

RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Kempke, Nils-Christian via Gdb-patches]

Hi Tom,

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Friday, January 14, 2022 9:06 PM
> To: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; Bernhard
> Heckel <bernhard.heckel@intel.com>
> Subject: Re: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> add support for accessing fields of extended types
> 
> >>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org> writes:
> 
> >> From: Bernhard Heckel <bernhard.heckel@intel.com>
> >> Fortran 2003 supports type extension.  This patch allows access
> >> to inherited members by using their fully qualified name as described
> >> in the Fortran standard.
> 
> Thanks for the patch.
> 
> >> In doing so the patch also fixes a bug in GDB when trying to access the
> >> members of a base class in a derived class via the derived class' base
> >> class member.
> 
> >> @@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
> >>        if (v)
> >>  	return v;
> 
> >> +      /* Fortran: If it is not a field it is the type name of an inherited
> >> +	 structure.  */
> >> +      v = search_struct_field (name, *argp, t, 1);
> >> +      if (v)
> >> +	return v;
> 
> Putting this here makes me wonder if it's possible to construct test
> cases in other languages that would work without this patch and then
> fail with it.

Well, since this patch so far did not care about the language actually used,
it enables one to do things like

  (gdb) p derived_obj
  $1 = {<base> = {...}, <No data fields>}
  (gdb) p derived_obj.base
  $2 = {...}

in all languages, which probably is unexpected.  The above example would be
C++ and some class "derived" inheriting from "base".  The syntax
derived_obj.base is no standard C++..
I am not sure whether one would actually break things since the only leftover
check in the method is a (according to the comment) C++ specific one for
member variables and I do not think that one can break C++ with the change.

> 
> I'm not sure what the options are though.  Doing the work elsewhere, say
> in a custom Fortran expression operation, might make the Python API
> harder to work with.  Maybe having value_struct_elt check
> current_language would work... that's also quite ugly but other value
> operations are doing that.

Mh, I am not too sure about the Fortran expression - would that not require
a Fortran specific version of value_struct_elt?  The methods
search_struct_method and search_struct_field are local to the valops.c file so
this would be a bigger redesign? I know that Ada has its own value_struct_elt
but it also implements the two helper methods.

Checking the language seems ok to me, considering the style of the rest of valops.

On more option that is also cleaner than directly checking the type might be to
generalize the concept of this "member access by base name" a bit and add a
method - say base_access_by_base_type_name - to language.h allowing or
disallowing an access to the base type by its type name.  Then one would have to
loop over all base types in valops.c as well.  I am not sure whether there exist other
languages that allow this kind of access though.. If not it might be a bit much?
 
Cheers,

Nils

> 
> Or maybe my fears are overblown.
> 
> Any thoughts on this?
> 
> Tom
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Kempke, Nils-Christian via Gdb-patches]

Kindly pinging for thoughts.

Cheers,
Nils

> -----Original Message-----
> From: Gdb-patches <gdb-patches-bounces+nils-
> christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke, Nils-
> Christian via Gdb-patches
> Sent: Monday, January 17, 2022 11:28 AM
> To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> patches <gdb-patches@sourceware.org>
> Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> add support for accessing fields of extended types
> 
> Hi Tom,
> 
> > -----Original Message-----
> > From: Tom Tromey <tom@tromey.com>
> > Sent: Friday, January 14, 2022 9:06 PM
> > To: Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org>
> > Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; Bernhard
> > Heckel <bernhard.heckel@intel.com>
> > Subject: Re: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> > add support for accessing fields of extended types
> >
> > >>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-
> > patches@sourceware.org> writes:
> >
> > >> From: Bernhard Heckel <bernhard.heckel@intel.com>
> > >> Fortran 2003 supports type extension.  This patch allows access
> > >> to inherited members by using their fully qualified name as described
> > >> in the Fortran standard.
> >
> > Thanks for the patch.
> >
> > >> In doing so the patch also fixes a bug in GDB when trying to access the
> > >> members of a base class in a derived class via the derived class' base
> > >> class member.
> >
> > >> @@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
> > >>        if (v)
> > >>  	return v;
> >
> > >> +      /* Fortran: If it is not a field it is the type name of an inherited
> > >> +	 structure.  */
> > >> +      v = search_struct_field (name, *argp, t, 1);
> > >> +      if (v)
> > >> +	return v;
> >
> > Putting this here makes me wonder if it's possible to construct test
> > cases in other languages that would work without this patch and then
> > fail with it.
> 
> Well, since this patch so far did not care about the language actually used,
> it enables one to do things like
> 
>   (gdb) p derived_obj
>   $1 = {<base> = {...}, <No data fields>}
>   (gdb) p derived_obj.base
>   $2 = {...}
> 
> in all languages, which probably is unexpected.  The above example would be
> C++ and some class "derived" inheriting from "base".  The syntax
> derived_obj.base is no standard C++..
> I am not sure whether one would actually break things since the only leftover
> check in the method is a (according to the comment) C++ specific one for
> member variables and I do not think that one can break C++ with the change.
> 
> >
> > I'm not sure what the options are though.  Doing the work elsewhere, say
> > in a custom Fortran expression operation, might make the Python API
> > harder to work with.  Maybe having value_struct_elt check
> > current_language would work... that's also quite ugly but other value
> > operations are doing that.
> 
> Mh, I am not too sure about the Fortran expression - would that not require
> a Fortran specific version of value_struct_elt?  The methods
> search_struct_method and search_struct_field are local to the valops.c file
> so
> this would be a bigger redesign? I know that Ada has its own value_struct_elt
> but it also implements the two helper methods.
> 
> Checking the language seems ok to me, considering the style of the rest of
> valops.
> 
> On more option that is also cleaner than directly checking the type might be
> to
> generalize the concept of this "member access by base name" a bit and add a
> method - say base_access_by_base_type_name - to language.h allowing or
> disallowing an access to the base type by its type name.  Then one would
> have to
> loop over all base types in valops.c as well.  I am not sure whether there exist
> other
> languages that allow this kind of access though.. If not it might be a bit much?
> 
> Cheers,
> 
> Nils
> 
> >
> > Or maybe my fears are overblown.
> >
> > Any thoughts on this?
> >
> > Tom
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Kempke, Nils-Christian via Gdb-patches]

[PING**2]

Cheers,
Nils

> -----Original Message-----
> From: Kempke, Nils-Christian
> Sent: Tuesday, February 1, 2022 4:07 PM
> To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> patches <gdb-patches@sourceware.org>
> Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> add support for accessing fields of extended types
> 
> Kindly pinging for thoughts.
> 
> Cheers,
> Nils
> 
> > -----Original Message-----
> > From: Gdb-patches <gdb-patches-bounces+nils-
> > christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke, Nils-
> > Christian via Gdb-patches
> > Sent: Monday, January 17, 2022 11:28 AM
> > To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> > patches <gdb-patches@sourceware.org>
> > Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> > add support for accessing fields of extended types
> >
> > Hi Tom,
> >
> > > -----Original Message-----
> > > From: Tom Tromey <tom@tromey.com>
> > > Sent: Friday, January 14, 2022 9:06 PM
> > > To: Nils-Christian Kempke via Gdb-patches <gdb-
> > patches@sourceware.org>
> > > Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; Bernhard
> > > Heckel <bernhard.heckel@intel.com>
> > > Subject: Re: [PATCH 1/2][PR fortran/26373][PR fortran/22497]
> gdb/fortran:
> > > add support for accessing fields of extended types
> > >
> > > >>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-
> > > patches@sourceware.org> writes:
> > >
> > > >> From: Bernhard Heckel <bernhard.heckel@intel.com>
> > > >> Fortran 2003 supports type extension.  This patch allows access
> > > >> to inherited members by using their fully qualified name as described
> > > >> in the Fortran standard.
> > >
> > > Thanks for the patch.
> > >
> > > >> In doing so the patch also fixes a bug in GDB when trying to access the
> > > >> members of a base class in a derived class via the derived class' base
> > > >> class member.
> > >
> > > >> @@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
> > > >>        if (v)
> > > >>  	return v;
> > >
> > > >> +      /* Fortran: If it is not a field it is the type name of an inherited
> > > >> +	 structure.  */
> > > >> +      v = search_struct_field (name, *argp, t, 1);
> > > >> +      if (v)
> > > >> +	return v;
> > >
> > > Putting this here makes me wonder if it's possible to construct test
> > > cases in other languages that would work without this patch and then
> > > fail with it.
> >
> > Well, since this patch so far did not care about the language actually used,
> > it enables one to do things like
> >
> >   (gdb) p derived_obj
> >   $1 = {<base> = {...}, <No data fields>}
> >   (gdb) p derived_obj.base
> >   $2 = {...}
> >
> > in all languages, which probably is unexpected.  The above example would
> be
> > C++ and some class "derived" inheriting from "base".  The syntax
> > derived_obj.base is no standard C++..
> > I am not sure whether one would actually break things since the only
> leftover
> > check in the method is a (according to the comment) C++ specific one for
> > member variables and I do not think that one can break C++ with the
> change.
> >
> > >
> > > I'm not sure what the options are though.  Doing the work elsewhere, say
> > > in a custom Fortran expression operation, might make the Python API
> > > harder to work with.  Maybe having value_struct_elt check
> > > current_language would work... that's also quite ugly but other value
> > > operations are doing that.
> >
> > Mh, I am not too sure about the Fortran expression - would that not
> require
> > a Fortran specific version of value_struct_elt?  The methods
> > search_struct_method and search_struct_field are local to the valops.c file
> > so
> > this would be a bigger redesign? I know that Ada has its own
> value_struct_elt
> > but it also implements the two helper methods.
> >
> > Checking the language seems ok to me, considering the style of the rest of
> > valops.
> >
> > On more option that is also cleaner than directly checking the type might be
> > to
> > generalize the concept of this "member access by base name" a bit and add
> a
> > method - say base_access_by_base_type_name - to language.h allowing
> or
> > disallowing an access to the base type by its type name.  Then one would
> > have to
> > loop over all base types in valops.c as well.  I am not sure whether there
> exist
> > other
> > languages that allow this kind of access though.. If not it might be a bit
> much?
> >
> > Cheers,
> >
> > Nils
> >
> > >
> > > Or maybe my fears are overblown.
> > >
> > > Any thoughts on this?
> > >
> > > Tom
> > Intel Deutschland GmbH
> > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> > Chairperson of the Supervisory Board: Nicole Lau
> > Registered Office: Munich
> > Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran: add support for accessing fields of extended types

[Kempke, Nils-Christian via Gdb-patches]

[PING**3]

Cheers,
Nils

> -----Original Message-----
> From: Kempke, Nils-Christian
> Sent: Thursday, February 10, 2022 2:20 PM
> To: 'Tom Tromey' <tom@tromey.com>; 'Nils-Christian Kempke via Gdb-
> patches' <gdb-patches@sourceware.org>
> Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> add support for accessing fields of extended types
> 
> [PING**2]
> 
> Cheers,
> Nils
> 
> > -----Original Message-----
> > From: Kempke, Nils-Christian
> > Sent: Tuesday, February 1, 2022 4:07 PM
> > To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> > patches <gdb-patches@sourceware.org>
> > Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497] gdb/fortran:
> > add support for accessing fields of extended types
> >
> > Kindly pinging for thoughts.
> >
> > Cheers,
> > Nils
> >
> > > -----Original Message-----
> > > From: Gdb-patches <gdb-patches-bounces+nils-
> > > christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke,
> Nils-
> > > Christian via Gdb-patches
> > > Sent: Monday, January 17, 2022 11:28 AM
> > > To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> > > patches <gdb-patches@sourceware.org>
> > > Subject: RE: [PATCH 1/2][PR fortran/26373][PR fortran/22497]
> gdb/fortran:
> > > add support for accessing fields of extended types
> > >
> > > Hi Tom,
> > >
> > > > -----Original Message-----
> > > > From: Tom Tromey <tom@tromey.com>
> > > > Sent: Friday, January 14, 2022 9:06 PM
> > > > To: Nils-Christian Kempke via Gdb-patches <gdb-
> > > patches@sourceware.org>
> > > > Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>;
> Bernhard
> > > > Heckel <bernhard.heckel@intel.com>
> > > > Subject: Re: [PATCH 1/2][PR fortran/26373][PR fortran/22497]
> > gdb/fortran:
> > > > add support for accessing fields of extended types
> > > >
> > > > >>>>> ">" == Nils-Christian Kempke via Gdb-patches <gdb-
> > > > patches@sourceware.org> writes:
> > > >
> > > > >> From: Bernhard Heckel <bernhard.heckel@intel.com>
> > > > >> Fortran 2003 supports type extension.  This patch allows access
> > > > >> to inherited members by using their fully qualified name as
> described
> > > > >> in the Fortran standard.
> > > >
> > > > Thanks for the patch.
> > > >
> > > > >> In doing so the patch also fixes a bug in GDB when trying to access
> the
> > > > >> members of a base class in a derived class via the derived class' base
> > > > >> class member.
> > > >
> > > > >> @@ -2374,6 +2374,12 @@ value_struct_elt (struct value **argp,
> > > > >>        if (v)
> > > > >>  	return v;
> > > >
> > > > >> +      /* Fortran: If it is not a field it is the type name of an inherited
> > > > >> +	 structure.  */
> > > > >> +      v = search_struct_field (name, *argp, t, 1);
> > > > >> +      if (v)
> > > > >> +	return v;
> > > >
> > > > Putting this here makes me wonder if it's possible to construct test
> > > > cases in other languages that would work without this patch and then
> > > > fail with it.
> > >
> > > Well, since this patch so far did not care about the language actually used,
> > > it enables one to do things like
> > >
> > >   (gdb) p derived_obj
> > >   $1 = {<base> = {...}, <No data fields>}
> > >   (gdb) p derived_obj.base
> > >   $2 = {...}
> > >
> > > in all languages, which probably is unexpected.  The above example
> would
> > be
> > > C++ and some class "derived" inheriting from "base".  The syntax
> > > derived_obj.base is no standard C++..
> > > I am not sure whether one would actually break things since the only
> > leftover
> > > check in the method is a (according to the comment) C++ specific one for
> > > member variables and I do not think that one can break C++ with the
> > change.
> > >
> > > >
> > > > I'm not sure what the options are though.  Doing the work elsewhere,
> say
> > > > in a custom Fortran expression operation, might make the Python API
> > > > harder to work with.  Maybe having value_struct_elt check
> > > > current_language would work... that's also quite ugly but other value
> > > > operations are doing that.
> > >
> > > Mh, I am not too sure about the Fortran expression - would that not
> > require
> > > a Fortran specific version of value_struct_elt?  The methods
> > > search_struct_method and search_struct_field are local to the valops.c
> file
> > > so
> > > this would be a bigger redesign? I know that Ada has its own
> > value_struct_elt
> > > but it also implements the two helper methods.
> > >
> > > Checking the language seems ok to me, considering the style of the rest
> of
> > > valops.
> > >
> > > On more option that is also cleaner than directly checking the type might
> be
> > > to
> > > generalize the concept of this "member access by base name" a bit and
> add
> > a
> > > method - say base_access_by_base_type_name - to language.h allowing
> > or
> > > disallowing an access to the base type by its type name.  Then one would
> > > have to
> > > loop over all base types in valops.c as well.  I am not sure whether there
> > exist
> > > other
> > > languages that allow this kind of access though.. If not it might be a bit
> > much?
> > >
> > > Cheers,
> > >
> > > Nils
> > >
> > > >
> > > > Or maybe my fears are overblown.
> > > >
> > > > Any thoughts on this?
> > > >
> > > > Tom
> > > Intel Deutschland GmbH
> > > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> > > Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> > > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> > > Chairperson of the Supervisory Board: Nicole Lau
> > > Registered Office: Munich
> > > Commercial Register: Amtsgericht Muenchen HRB 186928

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928