[PATCH 10/11] gdb: change default objfile iteration order to start with current objfile

[Simon Marchi <simon.marchi@efficios.com>]

From: Simon Marchi <simon.marchi@polymtl.ca>

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
---
 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 4017d0f4f27b..e7d6e634c168 100644
--- a/gdb/progspace.c
+++ b/gdb/progspace.c
@@ -153,8 +153,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 33dd4b2b1a32..a18f9b5bd0ec 100644
--- a/gdb/solib.c
+++ b/gdb/solib.c
@@ -479,8 +479,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 e2dfe4a8c93e..1df19a70adbf 100644
--- a/gdb/windows-tdep.c
+++ b/gdb/windows-tdep.c
@@ -832,9 +832,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.  */
@@ -893,43 +890,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;
-      }
-}
-
 /* Common parts for gdbarch initialization for the Windows and Cygwin OS
    ABIs.  */
 
-- 
2.52.0