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

["Kempke, Nils-Christian" <nils-christian.kempke@intel.com>]

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