Re: [RFC][PATCH 0/1] Fortran entry and DW_TAG_entry_point

[Kevin Buettner <kevinb@redhat.com>]

Hi Nils,

I skimmed the dwarf2/read.c part of the patch; I think it looks
reasonable, though I'd prefer that the comment introducing
add_partial_entry_point() not refer to Fortran entry points. 
(DW_TAG_entry point could be used for other languages too, right?)

As for the test case, I think you should use the DWARF assembler to
make a test case which uses DW_TAG_entry_point.  That way we don't
depend on having a compiler which outputs the correct info.  This test
case would be placed in gdb/testsuite/gdb.dwarf2 instead of
gdb/testsuite/gdb.fortran.

You can find existing test cases which use the DWARF assembler by
searching for "load_lib dwarf.exp" in the .exp files in
gdb/testsuite/gdb.dwarf2.  At present there are nearly 200 .exp files
which contain this line, so there are plenty of examples.

Kevin

On Wed, 23 Mar 2022 11:53:18 +0100
Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org> wrote:

> Hi,
> 
> please find attached a patch that enables GDB to parse the
> DW_TAG_entry_point DWARF tag.
> 
> It was already sent to the mailing list a while ago but got lost in
> review (see the commit message of the attached patch).
> 
> The patch was originally written with ifort in mind, the only compiler
> we know of, that actually emits the DW_TAG_entry_point.  It is used to
> describe alternative entry points to functions defined with Fortran's
> 'entry' keyword.  With this patch it becomes possible to define and hit
> breakpoints in an executable that uses the 'entry' feature and has been
> compiled with ifort.
> 
> Gfortran and ifx actually follow a different way to describe Fortran entry
> points.  Both emit a DW_TAG_subprogram instead.
> 
> Sadly, the DWARF emitted by ifort is not quite correct for the given
> test (or any other entry point test we tried).  Some parameters of
> subroutines and entry points have a wrong DWARF location description.  So
> even though hitting breakpoints is possible in the test, printing of the
> passed variables fails and running the test with ifort will still produce
> FAILs.
> 
> With this in mind, we were unsure what to do with this patch, thus the RFC.
> On the one hand we did not want the patch to be lost.  On the other hand the
> compiler the patch was written for has some issues in its emitted DWARF 
> and we do not know when these issues can/will get fixed.
> 
> Note, that the attached test only fully passes with gfortran.  Ifx, while
> able to define breakpoints at entry points, also has issues producing
> correct DWARF for entry points (using the DW_TAG_subprogram approach).
> 
> The patch was tested with the standard board, unix/-m32,
> navtive-gdbserver and native-extended-gdbserver and we did not find any
> regressions with these.
> 
> Any feedback is highly welcome.
> 
> Cheers!
> 
> Nils
> 
> Nils-Christian Kempke (1):
>   dwarf, fortran: add support for DW_TAG_entry_point
> 
>  gdb/dwarf2/read.c                         | 101 ++++++++++++++++++++++
>  gdb/testsuite/gdb.fortran/entry-point.exp |  67 ++++++++++++++
>  gdb/testsuite/gdb.fortran/entry-point.f90 |  48 ++++++++++
>  3 files changed, 216 insertions(+)
>  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
>