public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 0/2] Add debuginfod core file support
@ 2022-03-03  1:34 Aaron Merey
  2022-03-03  1:35 ` [PATCH 1/2] gdb: Add soname to build-id mapping for core files Aaron Merey
  2022-03-03  1:35 ` [PATCH 2/2] PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings Aaron Merey
  0 siblings, 2 replies; 14+ messages in thread
From: Aaron Merey @ 2022-03-03  1:34 UTC (permalink / raw)
  To: gdb-patches; +Cc: aburgess, tom, lsix, simon.marchi, Aaron Merey

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-03-21 18:23 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-03  1:34 [PATCH 0/2] Add debuginfod core file support Aaron Merey
2022-03-03  1:35 ` [PATCH 1/2] gdb: Add soname to build-id mapping for core files Aaron Merey
2022-03-04 14:53   ` Tom Tromey
2022-03-08  0:30     ` Aaron Merey
2022-03-11 15:23       ` Tom Tromey
2022-03-11 21:44         ` Aaron Merey
2022-03-18 19:03           ` Tom Tromey
2022-03-21 18:21             ` Aaron Merey
2022-03-03  1:35 ` [PATCH 2/2] PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings Aaron Merey
2022-03-04 15:20   ` Tom Tromey
2022-03-08  0:33     ` Aaron Merey
2022-03-11 15:27       ` Tom Tromey
2022-03-11 21:49         ` Aaron Merey
2022-03-21 18:22           ` Aaron Merey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).