From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Scx1JR7HTmpG0iwAWB0awg (envelope-from ) for ; Wed, 08 Jul 2026 17:54:38 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=caYku8po; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9567C1E04F; Wed, 08 Jul 2026 17:54:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0C1E81E04F for ; Wed, 08 Jul 2026 17:54:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A020D4BA2E11 for ; Wed, 8 Jul 2026 21:54:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A020D4BA2E11 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=caYku8po Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BA7AB4BA2E14 for ; Wed, 8 Jul 2026 21:54:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BA7AB4BA2E14 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BA7AB4BA2E14 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783547643; cv=none; b=AE77UQoGDMzBGUfQ4yRHuFAYAWxYobvVPjPx4a/U2TnBpyTNuNbbZsaacChAMu+LWG6zMervRgCTKp3qLBt2wUCRahnrFN97+w9+aG1bf7j8eO7vz5NtbNg7tqV4+cm0D1zRwQmqDkY7UfEbZxlEcy+nYi8waWdFrbK+ARnsgWI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783547643; c=relaxed/simple; bh=IXyf6riQupYW5fGwXUEbii4anqKmyFcF+t3OeEajAAc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=gTDFaqbF8e2deXyueyfIfhdoZFrjTQgFjUAdHJgrP1oT8D68TS1YLadBs5ztIV4a3lQxRVSsKvR5qTlFKhDQWL/nw8MJM7FMJPEyYAV850G9Lo0Vb7ws8UiYMBOgp88STPmK1/M14k9s17fRVrbmL0EMuW2QGA0l+05HnfTRb1U= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=caYku8po DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA7AB4BA2E14 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 668Lrrej118050 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2026 17:53:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 668Lrrej118050 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1783547638; bh=Px4bms6xv7AMpVlt5PwyfKEk1sqnIUhUVAiNUttp/98=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=caYku8pobrbfevQdAJgTs6dNvBrKPy6tUuEO4mdynMSHg/yPGkzk/ETON5elOSxBk gBqZQPLlF+SM5JHgOmk+AZY5EzxWcFSXqSD044KmilSq8/FUNX2aFOsqAGzj8fWkiQ XX6UFVYEi/S6dDpzRRcdNDAA8UV02vtkTcQ3qXrHjwUOWOSt65iQ8O8MstEZdAUzXg G6loGPfLJMJjAXy1UXf2oTdaVgseOWlbnzEwWZtdT8IajtEIaPMS5IjCoVI5sNN6yA hTFMdBvTG6ToO8Qbu7HOjG7FWzcPeNjWWvhJQFXiCF+6P6O7STkHtYTkIThEeTSJCK 7JSzbNGW7FMsw== Received: by simark.ca (Postfix) id 686661E090; Wed, 08 Jul 2026 17:53:53 -0400 (EDT) From: simon.marchi@polymtl.ca To: gdb-patches@sourceware.org Cc: Tom Tromey , Lancelot SIX , Simon Marchi Subject: [PATCH v3 09/10] gdb: change default objfile iteration order to start with current objfile Date: Wed, 8 Jul 2026 17:51:41 -0400 Message-ID: <20260708215145.93134-10-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260708215145.93134-1-simon.marchi@polymtl.ca> References: <20260708215145.93134-1-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 8 Jul 2026 21:53:53 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org From: Simon Marchi The current default objfile search strategy, defined both in solib_ops::iterate_over_objfiles_in_search_order (when the solib_ops hasn't overridden it) and in program_space::iterate_over_objfiles_in_search_order (when there is no solib_ops in the program space, for some reason), is to scan the objfile list linearly. program_space::iterate_over_objfiles_in_search_order: for (auto &objfile : this->objfiles ()) if (cb (&objfile)) return; solib_ops::iterate_over_objfiles_in_search_order: for (objfile &objfile : m_pspace->objfiles ()) if (cb (&objfile)) return; The following patch adds support for multiple concurrent solib_ops in a program space. Everything that deals with an solib_ops needs to be adapted to deal with multiple solib_ops, including program_space::iterate_over_objfiles_in_search_order. What I came up with for that method introduces a change in behavior where the current objfile will always be searched first. Rather than hide the change in behavior in that big patch, do it in this preparatory patch, in the hope that any potential problems it causes can be more easily bisected and analyzed. Concretely, the change is to check the current objfile first, in the two spots: if (current_objfile != nullptr && cb (current_objfile)) return; This happens to be what windows_solib_ops did, so remove that specialization. svr4_solib_ops already has its own iterate_over_objfiles_in_search_order that conditionally checks the current objfile first, based on the DT_SYMBOLIC dynamic tag. So it is not affected by this change. The solib_ops potentially affected by this change are (we know that rocm_solib_ops doesn't care): - frv_solib_ops - target_solib_ops - darwin_solib_ops - dsbt_solib_ops - aix_solib_ops I don't really know if searching objfiles in order (so, main objfile first typically) is essential for any of these solib_ops. Intuitively, searching the current objfile first makes sense, unless there is some fancy symbol interposition happening, in which case that solib_ops should probably implement a custom iterate_over_objfiles_in_search_order. Change-Id: I58195af6b53ca202e6061a5f36d5f74e1a0d5c17 Approved-By: Tom Tromey Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17003 --- gdb/progspace.c | 5 ++++- gdb/solib.c | 5 ++++- gdb/windows-tdep.c | 40 ---------------------------------------- 3 files changed, 8 insertions(+), 42 deletions(-) diff --git a/gdb/progspace.c b/gdb/progspace.c index 1407b058dfdf..7023ccddc546 100644 --- a/gdb/progspace.c +++ b/gdb/progspace.c @@ -128,8 +128,11 @@ program_space::iterate_over_objfiles_in_search_order return m_solib_ops->iterate_over_objfiles_in_search_order (cb, current_objfile); + if (current_objfile != nullptr && cb (current_objfile)) + return; + for (auto &objfile : this->objfiles ()) - if (cb (&objfile)) + if (&objfile != current_objfile && cb (&objfile)) return; } diff --git a/gdb/solib.c b/gdb/solib.c index b9b0f11cb477..6ed56aaf5159 100644 --- a/gdb/solib.c +++ b/gdb/solib.c @@ -451,8 +451,11 @@ solib_ops::iterate_over_objfiles_in_search_order (iterate_over_objfiles_in_search_order_cb_ftype cb, objfile *current_objfile) const { + if (current_objfile != nullptr && cb (current_objfile)) + return; + for (objfile &objfile : m_pspace->objfiles ()) - if (cb (&objfile)) + if (&objfile != current_objfile && cb (&objfile)) return; } diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c index 261c38b35635..d65e6e76faeb 100644 --- a/gdb/windows-tdep.c +++ b/gdb/windows-tdep.c @@ -829,9 +829,6 @@ struct windows_solib_ops : target_solib_ops using target_solib_ops::target_solib_ops; void create_inferior_hook (int from_tty) override; - void iterate_over_objfiles_in_search_order - (iterate_over_objfiles_in_search_order_cb_ftype cb, - objfile *current_objfile) const override; }; /* Return a new solib_ops for Windows systems. */ @@ -890,43 +887,6 @@ windows_solib_ops::create_inferior_hook (int from_tty) } } -/* Implement the "iterate_over_objfiles_in_search_order" gdbarch - method. It searches all objfiles, starting with CURRENT_OBJFILE - first (if not NULL). - - On Windows, the system behaves a little differently when two - objfiles each define a global symbol using the same name, compared - to other platforms such as GNU/Linux for instance. On GNU/Linux, - all instances of the symbol effectively get merged into a single - one, but on Windows, they remain distinct. - - As a result, it usually makes sense to start global symbol searches - with the current objfile before expanding it to all other objfiles. - This helps for instance when a user debugs some code in a DLL that - refers to a global variable defined inside that DLL. When trying - to print the value of that global variable, it would be unhelpful - to print the value of another global variable defined with the same - name, but in a different DLL. */ - -void -windows_solib_ops::iterate_over_objfiles_in_search_order - (iterate_over_objfiles_in_search_order_cb_ftype cb, - objfile *current_objfile) const -{ - if (current_objfile) - { - if (cb (current_objfile)) - return; - } - - for (objfile &objfile : m_pspace->objfiles ()) - if (&objfile != current_objfile) - { - if (cb (&objfile)) - return; - } -} - /* Implement the "auto_wide_charset" gdbarch method. */ static const char * -- 2.55.0