From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id BE5173858D39 for ; Thu, 3 Mar 2022 01:35:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE5173858D39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-653-9Gqnw8ZkPk2lStYnslSlqQ-1; Wed, 02 Mar 2022 20:35:48 -0500 X-MC-Unique: 9Gqnw8ZkPk2lStYnslSlqQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 187721091DA3; Thu, 3 Mar 2022 01:35:47 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.22.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id F2A735DF37; Thu, 3 Mar 2022 01:35:09 +0000 (UTC) From: Aaron Merey To: gdb-patches@sourceware.org Cc: aburgess@redhat.com, tom@tromey.com, lsix@lancelotsix.com, simon.marchi@polymtl.ca, Aaron Merey Subject: [PATCH 0/2] Add debuginfod core file support Date: Wed, 2 Mar 2022 20:34:59 -0500 Message-Id: <20220303013501.265407-1-amerey@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 01:35:56 -0000 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 wrote: > On Thu, Feb 17, 2022 at 5:48 PM Andrew Burgess wrote: > > Aaron Merey 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