[PATCH 0/2] Add debuginfod core file support

[Aaron Merey <amerey@redhat.com>]

For v4 of this series see
https://sourceware.org/pipermail/gdb-patches/2021-November/183291.html

The main change in v5 is that core file soname-to-build-id mappings are
no longer part of progspaces and are instead stored in the registry of
core file bfds.

This change was based on a suggestion from Andrew Burgess.  I've included
part of this discussion below since it appears that gdb-patches fell off
the cc list.  Originally we talked about adding the maps to progspace
registries but I decided to use bfd registries since the maps are
arguably more closely associated with the core file itself rather than
the progspace.

Aaron Merey (2):
  gdb: Add soname to build-id mapping for core files
  PR gdb/27570: missing support for debuginfod in
    core_target::build_file_mappings

 gdb/corelow.c                                 |  38 ++++++
 gdb/debuginfod-support.c                      |  51 +++++++
 gdb/debuginfod-support.h                      |  17 +++
 gdb/gcore.in                                  |   2 +-
 gdb/linux-tdep.c                              |  38 +++++-
 gdb/solib.c                                   | 128 ++++++++++++++++++
 gdb/solib.h                                   |  20 +++
 .../gdb.debuginfod/fetch_src_and_symbols.exp  |  22 +++
 8 files changed, 314 insertions(+), 2 deletions(-)

On Tue, Feb 22, 2022 at 8:45 PM Aaron Merey <amerey@redhat.com> wrote:
> On Thu, Feb 17, 2022 at 5:48 PM Andrew Burgess <aburgess@redhat.com> wrote:
> > Aaron Merey <amerey@redhat.com> writes:
> > > +  /* Associate a core file SONAME with BUILD_ID so that it can be retrieved
> > > +     with get_cbfd_soname_build_id.  */
> > > +  void set_cbfd_soname_build_id (std::string soname,
> > > +                              const bfd_build_id *build_id);
> > > +
> > > +  /* If a core file SONAME had a build-id associated with it by a previous
> > > +     call to set_cbfd_soname_build_id then return the build-id as a
> > > +     NULL-terminated hex string.  */
> > > +  const char *get_cbfd_soname_build_id (const char *soname);
> > > +
> > > +  /* Clear all core file soname to build-id mappings.  */
> > > +  void clear_cbfd_soname_build_ids ();
> > > +
> >
> > I don't know how you'd feel about it, but I have another suggestion,
> > that would remove the need to change progspace.* at all.
> >
> > So, I was always a little uncomfortable with this new bit of API because
> > it was so tied to core files.  I did wonder if we could rename it to
> > sound more generic.... but I think there's a better option:
> >
> >   register_program_space_data_with_cleanup (...)
> >
> > The program_space structure has a REGISTRY_FIELDS entry, which means it
> > supports carrying around arbitrary data payloads.  You can see this in
> > use in python/py-progspace.c.
> >
> > What this would allow you to do is move this new API off of progspace
> > and place it entirely within corelow.c.
> >
> > I don't know how you feel about this idea?
>
> It would be nice to avoid adding an extra API to progspace and I think
> the registry is a suitable alternative.  If I understand things correctly,
> we'll still use an unordered_map to associate sonames to build-ids but
> register this map with the current progspace so that the map is cleared
> when the progspace's dtor runs.

-- 
2.35.1