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

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

[Kempke, Nils-Christian]

Ping

> -----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: Thursday, May 12, 2022 12:39 PM
> To: Tom Tromey <tom@tromey.com>; Nils-Christian Kempke via Gdb-
> patches <gdb-patches@sourceware.org>
> Cc: 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
> 
> > -----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

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