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

Message ID 20220113163909.2880018-2-nils-christian.kempke@intel.com
State New
Headers show
Series
  • GDB support for Fortran extends feature
Related show

Commit Message

Simon Marchi via Gdb-patches Jan. 13, 2022, 4:39 p.m.
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

-- 
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

Comments

Tom Tromey Jan. 14, 2022, 8:06 p.m. | #1
>>>>> ">" == 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
Simon Marchi via Gdb-patches Jan. 17, 2022, 10:28 a.m. | #2
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

Patch

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,