From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by sourceware.org (Postfix) with ESMTPS id 96B313836E41 for ; Thu, 2 Jun 2022 14:29:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 96B313836E41 X-IronPort-AV: E=McAfee;i="6400,9594,10365"; a="258036219" X-IronPort-AV: E=Sophos;i="5.91,271,1647327600"; d="scan'208";a="258036219" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2022 07:29:02 -0700 X-IronPort-AV: E=Sophos;i="5.91,271,1647327600"; d="scan'208";a="707585632" Received: from labpc2407.iul.intel.com (HELO localhost) ([172.28.50.61]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2022 07:29:02 -0700 From: Markus Metzger To: gdb-patches@sourceware.org Subject: [PATCH v5 06/15] gdb, compile: unlink objfile stored in module Date: Thu, 2 Jun 2022 15:25:05 +0200 Message-Id: <20220602132514.957983-7-markus.t.metzger@intel.com> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220602132514.957983-1-markus.t.metzger@intel.com> References: <20220602132514.957983-1-markus.t.metzger@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 02 Jun 2022 14:29:06 -0000 When cleaning up after a compile command, we iterate over all objfiles and unlink the first objfile with the same name as the one we compiled. Since we already store a pointer to that objfile in the module and use it to get the name we're comparing against, there's no reason to iterate, at all. We can simply use that objfile. This further avoids potential issues when an objfile with the same name is loaded into a different linker namespace. --- gdb/compile/compile-object-run.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/gdb/compile/compile-object-run.c b/gdb/compile/compile-object-run.c index 331ae35c5e9..b9de626f4f0 100644 --- a/gdb/compile/compile-object-run.c +++ b/gdb/compile/compile-object-run.c @@ -79,21 +79,18 @@ do_module_cleanup (void *arg, int registers_valid) } } + objfile *objfile = data->module->objfile; + gdb_assert (objfile != nullptr); + /* We have to make a copy of the name so that we can unlink the underlying file -- removing the objfile will cause the name to be freed, so we can't simply keep a reference to it. */ - std::string objfile_name_s = objfile_name (data->module->objfile); - for (objfile *objfile : current_program_space->objfiles ()) - if ((objfile->flags & OBJF_USERLOADED) == 0 - && objfile_name_s == objfile_name (objfile)) - { - objfile->unlink (); - - /* It may be a bit too pervasive in this dummy_frame dtor callback. */ - clear_symtab_users (0); - - break; - } + std::string objfile_name_s = objfile_name (objfile); + + objfile->unlink (); + + /* It may be a bit too pervasive in this dummy_frame dtor callback. */ + clear_symtab_users (0); /* Delete the .c file. */ unlink (data->module->source_file.c_str ()); -- 2.35.3 Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, 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