[PATCH v2 0/1] Fortran entry and DW_TAG_entry_point

[PATCH v2 0/1] Fortran entry and DW_TAG_entry_point

[Nils-Christian Kempke]

Hi,

please find attached v2 of this series.  It introduced the handling
of DW_TAG_entry_point to GDB.

I want to emphasize again - between gfortran, ifort, and ifx only
ifort seems to currently emit this tag.  So the attached test only
really works when using ifort.  After a comment from Kevin I now added
a gdb.dwarf2 test for GDB's handling of this tag such that it can be
tested without the availablity of a compiler emitting it.

V1 can be found here, it was originally submitted as [RFC]:

https://sourceware.org/pipermail/gdb-patches/2022-March/186900.html

Changes since v1:

	* I rebased to master and removed the partial symbol stuff from
	this patch since this part has been reworked recently.  I hope I
	adapted to the changes correctly.
	* I added the handling of a DW_TAG_entry_points prefix in
	'determine_prefix' (after Jini pointing out a bug here).
	* I removed an if that checked for fortran as the cu's language
	in new_symbol and made the handling of DW_TAG_entry_point
	language agnostic.
	* I changed the return type of 'dwarf2_get_pc_bounds_entry_point'
	to also return PC_BOUNDS_RANGES if the parent die returns these.
	* I added a gdb.dwarf2 test to be able to check this test even
	when one does not have ifort at hand.  The new test compiles
	some .c helper with some labels and uses that to put some
	entry point dwarf on top.  It then checks whether we can break
	at the entry points.

Cheers!
Nils


Nils-Christian Kempke (1):
  dwarf, fortran: add support for DW_TAG_entry_point

 gdb/dwarf2/abbrev.c                           |   1 +
 gdb/dwarf2/read.c                             |  72 ++++++++-
 gdb/testsuite/gdb.dwarf2/dw2-entry-points.c   |  39 +++++
 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 149 ++++++++++++++++++
 gdb/testsuite/gdb.fortran/entry-point.exp     |  84 ++++++++++
 gdb/testsuite/gdb.fortran/entry-point.f90     |  67 ++++++++
 6 files changed, 411 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-points.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
 create mode 100644 gdb/testsuite/gdb.fortran/entry-point.exp
 create mode 100644 gdb/testsuite/gdb.fortran/entry-point.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 v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Nils-Christian Kempke]

Fortran provides additional entry points for subroutines and functions.
These entry points may use only a subset (or a different set) of the
parameters of the original subroutine.  The entry points may be described
via the DWARF tag DW_TAG_entry_point.

This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
Currently, between ifx/ifort/gfortran, only ifort is actually emitting
this tag.  Both, ifx and gfortran use the DW_TAG_subprogram tag as
workaround/alternative.  Thus, this patch really only adds more ifort
support.  Even so, some of the attached tests still fail for ifort, due
to some wrong line info generated for the entry points in ifort.

After this patch it is possible to set a breakpoint in gdb with the
ifort compiled example at the entry points 'foo' and 'foobar', which was not
possible before.

As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
which uses some underlying c compiled code and adds some Fortran style DWARF
to it emitting the DW_TAG_entry_point.  Before this patch it was not
possible to actually define breakpoint at the entry point tags.

For gfortran there actually exists a bug on bugzilla, asking for the use
of DW_TAG_entry_point over DW_TAG_subprogram:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134

This patch was originally posted here

https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html

but its review/pinging got lost after a while.  I reworked it to fit the
current GDB.

Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
Co-authored-by: Tim Wiederhake  <tim.wiederhake@intel.com>

Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
 gdb/dwarf2/abbrev.c                           |   1 +
 gdb/dwarf2/read.c                             |  72 ++++++++-
 gdb/testsuite/gdb.dwarf2/dw2-entry-points.c   |  39 +++++
 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 149 ++++++++++++++++++
 gdb/testsuite/gdb.fortran/entry-point.exp     |  84 ++++++++++
 gdb/testsuite/gdb.fortran/entry-point.f90     |  67 ++++++++
 6 files changed, 411 insertions(+), 1 deletion(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-points.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
 create mode 100644 gdb/testsuite/gdb.fortran/entry-point.exp
 create mode 100644 gdb/testsuite/gdb.fortran/entry-point.f90

diff --git a/gdb/dwarf2/abbrev.c b/gdb/dwarf2/abbrev.c
index 2db5ea15ac..3b47987a0e 100644
--- a/gdb/dwarf2/abbrev.c
+++ b/gdb/dwarf2/abbrev.c
@@ -88,6 +88,7 @@ tag_interesting_for_index (dwarf_tag tag)
     case DW_TAG_base_type:
     case DW_TAG_class_type:
     case DW_TAG_constant:
+    case DW_TAG_entry_point:
     case DW_TAG_enumeration_type:
     case DW_TAG_enumerator:
     case DW_TAG_imported_declaration:
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 698720276a..9d6b70d118 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -8656,6 +8656,7 @@ process_die (struct die_info *die, struct dwarf2_cu *cu)
 	  && die->parent->tag == DW_TAG_subprogram)
 	cu->processing_has_namespace_info = true;
       /* Fall through.  */
+    case DW_TAG_entry_point:
     case DW_TAG_inlined_subroutine:
       read_func_scope (die, cu);
       break;
@@ -8771,6 +8772,7 @@ die_needs_namespace (struct die_info *die, struct dwarf2_cu *cu)
     case DW_TAG_enumerator:
     case DW_TAG_subprogram:
     case DW_TAG_inlined_subroutine:
+    case DW_TAG_entry_point:
     case DW_TAG_member:
     case DW_TAG_imported_declaration:
       return 1;
@@ -13025,6 +13027,53 @@ dwarf2_ranges_read_low_addrs (unsigned offset, struct dwarf2_cu *cu,
     });
 }
 
+/* Determine the low and high pc of a DW_TAG_entry_point.  */
+
+static pc_bounds_kind
+dwarf2_get_pc_bounds_entry_point (die_info *die, CORE_ADDR *lowpc,
+				  CORE_ADDR *highpc, dwarf2_cu *cu)
+{
+  CORE_ADDR low = 0;
+  CORE_ADDR high = 0;
+
+  if (die->parent->tag != DW_TAG_subprogram)
+    {
+      complaint (_("DW_TAG_entry_point not embedded in DW_TAG_subprogram"));
+      return PC_BOUNDS_INVALID;
+    }
+
+  /* A DW_TAG_entry_point is embedded in an subprogram.  Therefore, we can use
+     the highpc from it's enveloping subprogram and get the lowpc from
+     DWARF.  */
+  const enum pc_bounds_kind bounds_kind = dwarf2_get_pc_bounds (die->parent,
+								&low, &high,
+								cu, nullptr,
+								nullptr);
+  if (bounds_kind == PC_BOUNDS_INVALID || bounds_kind == PC_BOUNDS_NOT_PRESENT)
+    return PC_BOUNDS_INVALID;
+
+  attribute *attr_low = dwarf2_attr (die, DW_AT_low_pc, cu);
+  if (!attr_low)
+    {
+      complaint (_("DW_TAG_entry_point is missing DW_AT_low_pc"));
+      return PC_BOUNDS_INVALID;
+    }
+  low = attr_low->as_address ();
+  if (high <= low)
+    return PC_BOUNDS_INVALID;
+  if (low == 0 && !cu->per_objfile->per_bfd->has_section_at_zero)
+    return PC_BOUNDS_INVALID;
+
+  if (lowpc)
+    *lowpc = low;
+  if (highpc)
+    *highpc = high;
+
+  /* Return PC_BOUNDS_RANGES/PC_BOUNDS_HIGH_LOW depending on the parent
+     die's bounds kind.  */
+  return bounds_kind;
+}
+
 /* Get low and high pc attributes from a die.  See enum pc_bounds_kind
    definition for the return value.  *LOWPC and *HIGHPC are set iff
    neither PC_BOUNDS_NOT_PRESENT nor PC_BOUNDS_INVALID are returned.  */
@@ -13041,6 +13090,9 @@ dwarf2_get_pc_bounds (struct die_info *die, CORE_ADDR *lowpc,
   CORE_ADDR high = 0;
   enum pc_bounds_kind ret;
 
+  if (die->tag == DW_TAG_entry_point)
+    return dwarf2_get_pc_bounds_entry_point (die, lowpc, highpc, cu);
+
   attr_high = dwarf2_attr (die, DW_AT_high_pc, cu);
   if (attr_high)
     {
@@ -20736,6 +20788,20 @@ new_symbol (struct die_info *die, struct type *type, struct dwarf2_cu *cu,
 	  sym->set_domain (LABEL_DOMAIN);
 	  add_symbol_to_list (sym, cu->list_in_scope);
 	  break;
+	case DW_TAG_entry_point:
+	  /* SYMBOL_BLOCK_VALUE (sym) will be filled in later by
+	     finish_block.  */
+	  sym->set_aclass_index (LOC_BLOCK);
+	  /* DW_TAG_entry_point provides an additional entry_point to an
+	     existing sub_program.  Therefore, we inherit the "external"
+	     attribute from the sub_program to which the entry_point
+	     belongs to.  */
+	  attr2 = dwarf2_attr (die->parent, DW_AT_external, cu);
+	  if (attr2 != nullptr && attr2->as_boolean ())
+	    list_to_add = cu->get_builder ()->get_global_symbols ();
+	  else
+	    list_to_add = cu->list_in_scope;
+	  break;
 	case DW_TAG_subprogram:
 	  /* SYMBOL_BLOCK_VALUE (sym) will be filled in later by
 	     finish_block.  */
@@ -21440,6 +21506,7 @@ read_type_die_1 (struct die_info *die, struct dwarf2_cu *cu)
     case DW_TAG_enumeration_type:
       this_type = read_enumeration_type (die, cu);
       break;
+    case DW_TAG_entry_point:
     case DW_TAG_subprogram:
     case DW_TAG_subroutine_type:
     case DW_TAG_inlined_subroutine:
@@ -21759,12 +21826,15 @@ determine_prefix (struct die_info *die, struct dwarf2_cu *cu)
 	return "";
       case DW_TAG_subprogram:
 	/* Nested subroutines in Fortran get a prefix with the name
-	   of the parent's subroutine.  */
+	   of the parent's subroutine.  Entry points are prefixed by the
+	   parent's namespace.  */
 	if (cu->per_cu->lang == language_fortran)
 	  {
 	    if ((die->tag ==  DW_TAG_subprogram)
 		&& (dwarf2_name (parent, cu) != NULL))
 	      return dwarf2_name (parent, cu);
+	    else if (die->tag == DW_TAG_entry_point)
+	      return determine_prefix (parent, cu);
 	  }
 	return "";
       case DW_TAG_enumeration_type:
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.c b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.c
new file mode 100644
index 0000000000..e8c99d1f52
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.c
@@ -0,0 +1,39 @@
+/* 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/>.  */
+
+/* In the generated DWARF, we'll use the locations of foo_entry_label and
+   foobar_entry_label as the low_pc's of our entry point TAGs.  */
+
+int I = 0;
+int J = 0;
+int K = 0;
+
+__attribute__((noinline))
+void bar_helper () {
+  __asm__("bar_helper_label: .globl bar_helper_label");
+  I++;
+  J++;
+  __asm__("foo_entry_label: .globl foo_entry_label");
+  J++;
+  K++;
+  __asm__("foobar_entry_label: .globl foobar_entry_label");
+}
+
+int main() {
+  __asm__("main_label: .globl main_label");
+  bar_helper ();
+
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
new file mode 100644
index 0000000000..bdb4ce6eaf
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
@@ -0,0 +1,149 @@
+# 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 that the DW_TAG_entry_point is handled properly by GDB and that we can
+# set breakpoints on function entry points.
+
+load_lib dwarf.exp
+
+# This test can only be run on targets that support DWARF-2 and use
+# gas.
+if {![dwarf2_support]} {
+    return 0
+}
+
+standard_testfile .c -dw.S
+
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+	return -1
+}
+
+set int_size [get_sizeof "int" 4]
+
+# Make some DWARF for the test.
+set asm_file [standard_output_file $srcfile2]
+Dwarf::assemble $asm_file {
+    global srcfile
+    declare_labels int_label
+
+    get_func_info main
+    get_func_info bar_helper
+
+    set prog_line 1
+    set bar_line 2
+    set foo_line 3
+    set foobar_line 4
+
+    set global_I [gdb_target_symbol I]
+    set global_J [gdb_target_symbol J]
+    set global_K [gdb_target_symbol K]
+
+    cu {} {
+	compile_unit {
+	    {language @DW_LANG_Fortran90}
+	    {name dw2-entry-points.f90}
+	    {comp_dir /tmp}
+	} {
+	    int_label: base_type {
+		{name "int"}
+		{byte_size 4 sdata}
+		{encoding @DW_ATE_signed}
+	    }
+	    subprogram {
+		{name prog}
+		{decl_file 1 data1}
+		{decl_line $prog_line data1}
+		{low_pc $main_start addr}
+		{high_pc "$main_start + $main_len" addr}
+		{external 1 flag}
+		{main_subprogram 1 flag}
+	    }
+	    subprogram {
+		{name bar}
+		{decl_file 1 data1}
+		{decl_line $bar_line data1}
+		{external 1 flag}
+		{low_pc $bar_helper_start addr}
+		{high_pc "$bar_helper_start + $bar_helper_len" addr}
+	    } {
+		formal_parameter {
+		    {name I}
+		    {type :$int_label}
+		    {location {addr $global_I} SPECIAL_expr}
+		}
+		formal_parameter {
+		    {name J}
+		    {type :$int_label}
+		    {location {addr $global_J} SPECIAL_expr}
+		}
+		entry_point {
+		    {name foo}
+		    {decl_file 1 data1}
+		    {decl_line $foo_line data1}
+		    {low_pc foo_entry_label addr}
+		} {
+		    formal_parameter {
+			{name J}
+			{type :$int_label}
+			{location {addr $global_J} SPECIAL_expr}
+		    }
+		    formal_parameter {
+			{name K}
+			{type :$int_label}
+			{location {addr $global_K} SPECIAL_expr}
+		    }
+		}
+		entry_point {
+			{name foobar}
+			{decl_file 1 data1}
+			{decl_line $foobar_line data1}
+			{low_pc foobar_entry_label addr}
+		    } {
+		    formal_parameter {
+			{name J}
+			{type :$int_label}
+			{location {addr $global_J} SPECIAL_expr}
+		    }
+		}
+	    }
+	}
+    }
+}
+
+if {[prepare_for_testing "failed to prepare" ${testfile} \
+	 [list $srcfile $asm_file] {nodebug}]} {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+# Try whether we can set and hit breakpoints at the entry_points.
+gdb_breakpoint "foo"
+gdb_breakpoint "foobar"
+
+# Now hit the entry_point break point and check their call-stack.
+gdb_continue_to_breakpoint "foo"
+gdb_test "bt" [multi_line \
+		   "#0.*${hex} in foo \\(J=1, K=0\\).*" \
+		   "#1.*${hex} in prog \\(\\).*" \
+    ] "bt foo"
+
+gdb_continue_to_breakpoint "foobar"
+gdb_test "bt" [multi_line \
+		   "#0.*${hex} in foobar \\(J=2\\).*" \
+		   "#1.*${hex} in prog \\(\\).*" \
+    ] "bt foobar"
diff --git a/gdb/testsuite/gdb.fortran/entry-point.exp b/gdb/testsuite/gdb.fortran/entry-point.exp
new file mode 100644
index 0000000000..679191f79f
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/entry-point.exp
@@ -0,0 +1,84 @@
+# 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 entry points for subroutines.
+
+if { [skip_fortran_tests] } { return -1 }
+
+standard_testfile .f90
+load_lib "fortran.exp"
+
+if { [prepare_for_testing $testfile.exp $testfile $srcfile {debug f90}] } {
+    return -1
+}
+
+if { ![fortran_runto_main] } {
+    untested "could not run to main"
+    return -1
+}
+
+# Test if we can set a breakpoint via the entry-point name.
+set entry_point_name "foo"
+gdb_breakpoint $entry_point_name
+gdb_continue_to_breakpoint "continue to breakpoint: $entry_point_name" \
+    ".*entry foo\\(J,K,L,I1\\).*"
+
+gdb_test "print j" "= 11" "print j, entered via $entry_point_name"
+gdb_test "print k" "= 22" "print k, entered via $entry_point_name"
+gdb_test "print l" "= 33" "print l, entered via $entry_point_name"
+gdb_test "print i1" "= 44" "print i1, entered via $entry_point_name"
+gdb_test "info args" \
+    [multi_line "j = 11" \
+		"k = 22" \
+		"l = 33" \
+		"i1 = 44"] \
+    "info args, entered via $entry_point_name"
+
+# Test if we can set a breakpoint via the function name.
+set entry_point_name "bar"
+gdb_breakpoint $entry_point_name
+gdb_continue_to_breakpoint "continue to breakpoint: $entry_point_name" \
+    ".*subroutine bar\\(I,J,K,I1\\).*"
+
+gdb_test "print i" "= 444" "print i, entered via $entry_point_name"
+gdb_test "print j" "= 555" "print j, entered via $entry_point_name"
+gdb_test "print k" "= 666" "print k, entered via $entry_point_name"
+gdb_test "print i1" "= 777" "print i1, entered via $entry_point_name"
+
+# Test a second entry point.
+set entry_point_name "foobar"
+gdb_breakpoint $entry_point_name
+gdb_continue_to_breakpoint "continue to breakpoint: $entry_point_name" \
+    ".* entry foobar\\(J\\).*"
+
+gdb_test "print j" "= 1" "print j, entered via $entry_point_name"
+gdb_test "info args" "j = 1" "info args, entered via $entry_point_name"
+
+# Test breaking at the entrypoint defined inside the module mod via its
+# scoped name.
+set entry_point_name "mod::mod_foo"
+
+# GCC moves subroutines with entry points out of the module scope into the
+# compile unit scope.
+if {[test_compiler_info {gcc-*}]} {
+    setup_xfail "gcc/105272" *-*-*
+}
+gdb_breakpoint $entry_point_name
+
+if {[test_compiler_info {gcc-*}]} {
+    setup_xfail "gcc/105272" *-*-*
+}
+gdb_continue_to_breakpoint "continue to breakpoint: $entry_point_name" \
+    ".* entry mod_foo\\(\\).*"
diff --git a/gdb/testsuite/gdb.fortran/entry-point.f90 b/gdb/testsuite/gdb.fortran/entry-point.f90
new file mode 100644
index 0000000000..12a0557e78
--- /dev/null
+++ b/gdb/testsuite/gdb.fortran/entry-point.f90
@@ -0,0 +1,67 @@
+! 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/>.
+
+module mod
+implicit none
+
+contains
+  subroutine mod_bar
+    integer :: I = 3
+
+    goto 100
+
+    entry mod_foo
+    I = 33
+
+100 print *, I
+  end subroutine mod_bar
+end module mod
+
+
+subroutine bar(I,J,K,I1)
+  integer :: I,J,K,L,I1
+  integer :: A
+  real :: C
+
+  A = 0
+  C = 0.0
+
+  A = I + K + I1
+  goto 300
+
+  entry foo(J,K,L,I1)
+  A = J + K + L + I1
+
+200 C = J
+  goto 300
+
+  entry foobar(J)
+  goto 200
+
+300 A = C + 1
+  C = J * 1.5
+
+  return
+end subroutine
+
+program TestEntryPoint
+  use mod
+
+  call foo(11,22,33,44)
+  call bar(444,555,666,777)
+  call foobar(1)
+
+  call mod_foo()
+end program TestEntryPoint
-- 
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 v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Kevin Buettner]

On Thu, 14 Apr 2022 11:41:08 +0200
Nils-Christian Kempke <nils-christian.kempke@intel.com> wrote:

> Fortran provides additional entry points for subroutines and functions.
> These entry points may use only a subset (or a different set) of the
> parameters of the original subroutine.  The entry points may be described
> via the DWARF tag DW_TAG_entry_point.
> 
> This commit adds support for parsing the DW_TAG_entry_point DWARF tag.
> Currently, between ifx/ifort/gfortran, only ifort is actually emitting
> this tag.  Both, ifx and gfortran use the DW_TAG_subprogram tag as
> workaround/alternative.  Thus, this patch really only adds more ifort
> support.  Even so, some of the attached tests still fail for ifort, due
> to some wrong line info generated for the entry points in ifort.
> 
> After this patch it is possible to set a breakpoint in gdb with the
> ifort compiled example at the entry points 'foo' and 'foobar', which was not
> possible before.
> 
> As gcc and ifx do not emit the tag I also added a test to gdb.dwarf2
> which uses some underlying c compiled code and adds some Fortran style DWARF
> to it emitting the DW_TAG_entry_point.  Before this patch it was not
> possible to actually define breakpoint at the entry point tags.
> 
> For gfortran there actually exists a bug on bugzilla, asking for the use
> of DW_TAG_entry_point over DW_TAG_subprogram:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37134
> 
> This patch was originally posted here
> 
> https://sourceware.org/legacy-ml/gdb-patches/2017-07/msg00317.html
> 
> but its review/pinging got lost after a while.  I reworked it to fit the
> current GDB.
> 
> Co-authored-by: Bernhard Heckel <bernhard.heckel@intel.com>
> Co-authored-by: Tim Wiederhake  <tim.wiederhake@intel.com>
> 
> Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

Okay.

(Thanks for adding the new test!)

Kevin

Re: [PATCH v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Tom Tromey]

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

> diff --git a/gdb/dwarf2/abbrev.c b/gdb/dwarf2/abbrev.c
> index 2db5ea15ac..3b47987a0e 100644
> --- a/gdb/dwarf2/abbrev.c
> +++ b/gdb/dwarf2/abbrev.c
> @@ -88,6 +88,7 @@ tag_interesting_for_index (dwarf_tag tag)
>      case DW_TAG_base_type:
>      case DW_TAG_class_type:
>      case DW_TAG_constant:
> +    case DW_TAG_entry_point:
>      case DW_TAG_enumeration_type:
>      case DW_TAG_enumerator:
>      case DW_TAG_imported_declaration:

I wonder what happens if this is removed.

If it's needed I suppose I would expect some other changes to the
indexer.  Like maybe cooked_indexer::index_dies has to handle it, or
cooked_index_entry::matches(search_domain).

Tom

RE: [PATCH v2 0/1] Fortran entry and DW_TAG_entry_point

[George, Jini Susan]

[AMD Official Use Only]

Thank you, Nils, for making the changes. The code part of the patch (I did not look at the tests) LGTM except for one nit.

In dwarf2_get_pc_bounds_entry_point(),
...
the highpc from it's enveloping subprogram and get the lowpc from
...

"it's" needs to be changed to "its"

Thanks,
Jini.

>>-----Original Message-----
>>From: Nils-Christian Kempke <nils-christian.kempke@intel.com>
>>Sent: Thursday, April 14, 2022 3:11 PM
>>To: gdb-patches@sourceware.org
>>Cc: George, Jini Susan <JiniSusan.George@amd.com>; kevinb@redhat.com;
>>Nils-Christian Kempke <nils-christian.kempke@intel.com>
>>Subject: [PATCH v2 0/1] Fortran entry and DW_TAG_entry_point
>>
>>[CAUTION: External Email]
>>
>>Hi,
>>
>>please find attached v2 of this series.  It introduced the handling of
>>DW_TAG_entry_point to GDB.
>>
>>I want to emphasize again - between gfortran, ifort, and ifx only ifort seems to
>>currently emit this tag.  So the attached test only really works when using ifort.
>>After a comment from Kevin I now added a gdb.dwarf2 test for GDB's handling
>>of this tag such that it can be tested without the availablity of a compiler
>>emitting it.
>>
>>V1 can be found here, it was originally submitted as [RFC]:
>>
>>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource
>>ware.org%2Fpipermail%2Fgdb-patches%2F2022-
>>March%2F186900.html&amp;data=04%7C01%7Cjinisusan.george%40amd.com
>>%7Ca08c7e55cfad4480c8cc08da1dfaf41f%7C3dd8961fe4884e608e11a82d994e
>>183d%7C0%7C0%7C637855260922818318%7CUnknown%7CTWFpbGZsb3d8eyJ
>>WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
>>3000&amp;sdata=hM3fCyuREy4Aj8XBeNaAb4HL%2B8mkBQAfuyAnpK5trCs%3D
>>&amp;reserved=0
>>
>>Changes since v1:
>>
>>        * I rebased to master and removed the partial symbol stuff from
>>        this patch since this part has been reworked recently.  I hope I
>>        adapted to the changes correctly.
>>        * I added the handling of a DW_TAG_entry_points prefix in
>>        'determine_prefix' (after Jini pointing out a bug here).
>>        * I removed an if that checked for fortran as the cu's language
>>        in new_symbol and made the handling of DW_TAG_entry_point
>>        language agnostic.
>>        * I changed the return type of 'dwarf2_get_pc_bounds_entry_point'
>>        to also return PC_BOUNDS_RANGES if the parent die returns these.
>>        * I added a gdb.dwarf2 test to be able to check this test even
>>        when one does not have ifort at hand.  The new test compiles
>>        some .c helper with some labels and uses that to put some
>>        entry point dwarf on top.  It then checks whether we can break
>>        at the entry points.
>>
>>Cheers!
>>Nils
>>
>>
>>Nils-Christian Kempke (1):
>>  dwarf, fortran: add support for DW_TAG_entry_point
>>
>> gdb/dwarf2/abbrev.c                           |   1 +
>> gdb/dwarf2/read.c                             |  72 ++++++++-
>> gdb/testsuite/gdb.dwarf2/dw2-entry-points.c   |  39 +++++
>> gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 149 ++++++++++++++++++
>> gdb/testsuite/gdb.fortran/entry-point.exp     |  84 ++++++++++
>> gdb/testsuite/gdb.fortran/entry-point.f90     |  67 ++++++++
>> 6 files changed, 411 insertions(+), 1 deletion(-)  create mode 100644
>>gdb/testsuite/gdb.dwarf2/dw2-entry-points.c
>> create mode 100644 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
>> create mode 100644 gdb/testsuite/gdb.fortran/entry-point.exp
>> create mode 100644 gdb/testsuite/gdb.fortran/entry-point.f90
>>
>>--
>>2.25.1
>>
>>Intel Deutschland GmbH
>>Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
>>Tel: +49 89 99 8853-0,
>>https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.int
>>el.de%2F&amp;data=04%7C01%7Cjinisusan.george%40amd.com%7Ca08c7e55c
>>fad4480c8cc08da1dfaf41f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C
>>0%7C637855260922818318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sda
>>ta=de639g%2BROumUaBh9WP3GXaakd%2BW7VuTW%2F6YDJA9c5N4%3D&am
>>p;reserved=0
>><https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.in
>>tel.de%2F&amp;data=04%7C01%7Cjinisusan.george%40amd.com%7Ca08c7e55
>>cfad4480c8cc08da1dfaf41f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7
>>C0%7C637855260922818318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sd
>>ata=de639g%2BROumUaBh9WP3GXaakd%2BW7VuTW%2F6YDJA9c5N4%3D&a
>>mp;reserved=0>
>>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 v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Friday, April 15, 2022 5:28 PM
> To: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Kempke, Nils-Christian <nils-christian.kempke@intel.com>;
> jinisusan.george@amd.com; Tim Wiederhake <tim.wiederhake@intel.com>;
> Bernhard Heckel <bernhard.heckel@intel.com>
> Subject: Re: [PATCH v2 1/1] dwarf, fortran: add support for
> DW_TAG_entry_point
> 
> >>>>> Nils-Christian Kempke via Gdb-patches <gdb-
> patches@sourceware.org> writes:
> 
> > diff --git a/gdb/dwarf2/abbrev.c b/gdb/dwarf2/abbrev.c
> > index 2db5ea15ac..3b47987a0e 100644
> > --- a/gdb/dwarf2/abbrev.c
> > +++ b/gdb/dwarf2/abbrev.c
> > @@ -88,6 +88,7 @@ tag_interesting_for_index (dwarf_tag tag)
> >      case DW_TAG_base_type:
> >      case DW_TAG_class_type:
> >      case DW_TAG_constant:
> > +    case DW_TAG_entry_point:
> >      case DW_TAG_enumeration_type:
> >      case DW_TAG_enumerator:
> >      case DW_TAG_imported_declaration:
> 
> I wonder what happens if this is removed.
> 
> If it's needed I suppose I would expect some other changes to the
> indexer.  Like maybe cooked_indexer::index_dies has to handle it, or
> cooked_index_entry::matches(search_domain).
> 
> Tom

Hi Tom,

So, I have tried this and without this line we'd loose the possibility to do
do something like

   gdb ./outputs/gdb.fortran/entry-point/entry-point
   (gdb) b foo
   Breakpoint 1 at 0x404202 ..., line 33.

Removing it would show

   (gdb) b foo
   Function "foo" not defined.
   Make breakpoint pending on future shared library load? (y or [n]) n

I am honestly not quite sure about the two parts you pointed out.
What I think I understand it this:

In cooked_index_entry::matches(search_domain) we could add the
DW_TAG_entry_point to the FUNCTIONS_DOMAIN (similar to
DW_TAG_subroutine). Not sure if this would be wanted but I think
this is quite reasonable. Entry points are virtually like separate functions
with their own argument lists.

I am not sure what this would actually change within GDB though - commands
like 'info functions' and 'info module functions'

   (gdb) info functions
   All defined functions:

   File .../entry-point.f90:
   33:     void bar(INTEGER(4), INTEGER(4), INTEGER(4), INTEGER(4));
   44:     void foo(INTEGER(4), INTEGER(4), INTEGER(4), INTEGER(4));
   50:     void foobar(INTEGER(4));
   19:     void mod::MOD(void);
   20:     void mod::mod_bar(void);
   25:     void mod::mod_foo(void);
   59:     void testentrypoint(void);

   (gdb) info module functions
   All functions in all modules:

   Module "mod":

   File .../entry-point.f90:
   19:     void mod::MOD(void);
   20:     void mod::mod_bar(void);
   25:     void mod::mod_foo(void);

Seem to be ok without this as well. But maybe it still makes sense to add it here?

The other part you mentioned is cooked_indexer::index_dies. I think here the
change you meant is to recurse the entry if it is a DW_TAG_entry_point? In my
understanding this would then also index possibly interesting child DIEs, right?

Here, I am not sure whether a DW_TAG_entry_point can even have interesting
child dies. It will not possess any other DW_TAG_entry_point/DW_TAG_subprogram
tags I think.  So far I only know it can have DW_TAG_formal_parameter,
DW_TAG_unspecified_parameters and DW_TAG_common_inclusion. But I guess
it would not hurt to also add it here and it might catch child entries that I do not
think of right now.

I hope I understood this part correctly.

Currently, I am inclined to add the DW_TAG_entry_point to the functions domain,
about the second change I am not quite sure (currently DW_TAG_subprogram tags
are only recursed if the language is ada/fortran.

Thanks!
Nils 
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 v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Tom Tromey]

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

>> If it's needed I suppose I would expect some other changes to the
>> indexer.  Like maybe cooked_indexer::index_dies has to handle it, or
>> cooked_index_entry::matches(search_domain).

> I am honestly not quite sure about the two parts you pointed out.
> What I think I understand it this:

> In cooked_index_entry::matches(search_domain) we could add the
> DW_TAG_entry_point to the FUNCTIONS_DOMAIN (similar to
> DW_TAG_subroutine). Not sure if this would be wanted but I think
> this is quite reasonable. Entry points are virtually like separate functions
> with their own argument lists.

> I am not sure what this would actually change within GDB though - commands
> like 'info functions' and 'info module functions'

The test case in this situation is to have an entry point in some other
CU -- not the same one with the program's "main" -- and then try to
"break" on the entry point.

I think this should make gdb try to look up the function via the index,
but since the matching will fail, I suspect it won't cause CU expansion,
and so the entry point won't be found.

> The other part you mentioned is cooked_indexer::index_dies. I think here the
> change you meant is to recurse the entry if it is a DW_TAG_entry_point? In my
> understanding this would then also index possibly interesting child DIEs, right?

Yeah, I think I was mistaken about this one.

thanks,
Tom

RE: [PATCH v2 1/1] dwarf, fortran: add support for DW_TAG_entry_point

[Kempke, Nils-Christian]

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Thursday, May 26, 2022 7:35 PM
> To: Kempke, Nils-Christian via Gdb-patches <gdb-patches@sourceware.org>
> Cc: Tom Tromey <tom@tromey.com>; Kempke, Nils-Christian <nils-
> christian.kempke@intel.com>; jinisusan.george@amd.com; Bernhard Heckel
> <bernhard.heckel@intel.com>; Tim Wiederhake
> <tim.wiederhake@intel.com>
> Subject: Re: [PATCH v2 1/1] dwarf, fortran: add support for
> DW_TAG_entry_point
> 
> >>>>> Kempke, Nils-Christian via Gdb-patches <gdb-
> patches@sourceware.org> writes:
> 
> >> If it's needed I suppose I would expect some other changes to the
> >> indexer.  Like maybe cooked_indexer::index_dies has to handle it, or
> >> cooked_index_entry::matches(search_domain).
> 
> > I am honestly not quite sure about the two parts you pointed out.
> > What I think I understand it this:
> 
> > In cooked_index_entry::matches(search_domain) we could add the
> > DW_TAG_entry_point to the FUNCTIONS_DOMAIN (similar to
> > DW_TAG_subroutine). Not sure if this would be wanted but I think
> > this is quite reasonable. Entry points are virtually like separate functions
> > with their own argument lists.
> 
> > I am not sure what this would actually change within GDB though -
> commands
> > like 'info functions' and 'info module functions'
> 
> The test case in this situation is to have an entry point in some other
> CU -- not the same one with the program's "main" -- and then try to
> "break" on the entry point.
> 
> I think this should make gdb try to look up the function via the index,
> but since the matching will fail, I suspect it won't cause CU expansion,
> and so the entry point won't be found.
> 
> > The other part you mentioned is cooked_indexer::index_dies. I think here
> the
> > change you meant is to recurse the entry if it is a DW_TAG_entry_point? In
> my
> > understanding this would then also index possibly interesting child DIEs,
> right?
> 
> Yeah, I think I was mistaken about this one.
> 
> thanks,
> Tom

Hi Tom,

It took me a while but now: yes, you are right - when compiling (with ifort) e.g.
a static library containing an entry point, linking it and trying to break on the
entry point the symbol lookup fails as the symtab is not created.

I added the entry_point to the FUNCTIONS_DOMAIN now and also found another
place where I probably had missed to add DW_TAG_entry_point.  In
write_cooked_index I added it to the GDB_INDEX_SYMBOL_KIND_FUNCTION.

I adapted the testcase and added a second cu to the DWARF testing the lookup of
the entry_point.

I'll send a v3 soon with these changes.

Thanks,
Nils
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