diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2025-07-15 11:52:32 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2025-08-22 10:45:47 -0400 |
commit | fbb487b4510dc2cd6cf7e82df062d7e40eeb8c27 (patch) | |
tree | 182a46a997ce1459329c1a0572a7568a300f2fc8 /gdb/testsuite/gdb.python/py-read-memory-leak.py | |
parent | 77c87c12b3596567e4ac41b496cb4bac602d0dc3 (diff) | |
download | gdb-fbb487b4510dc2cd6cf7e82df062d7e40eeb8c27.zip gdb-fbb487b4510dc2cd6cf7e82df062d7e40eeb8c27.tar.gz gdb-fbb487b4510dc2cd6cf7e82df062d7e40eeb8c27.tar.bz2 |
gdb: make iterate_over_objfiles_in_search_order methods of program_space and solib_ops
Change the "iterate over objfiles in search order" operation from a
gdbarch method to methods on both program_space and solib_ops.
The first motivation for this is that I want to encapsulate solib-svr4's
data into svr4_solib_ops (in a subsequent series), instead of it being
in a separate structure (svr4_info). It is awkward to do so as long as
there are entry points that aren't the public solib_ops interface.
The second motivation is my project of making it able to have multiple
solib_ops per program space (which should be the subject of said
subsequent series), to better support heterogenousa systems (like ROCm,
with CPU and GPU in the same inferior). When we have this, when stopped
in GPU code, it won't make sense to ask the host's architecture to do
the iteration, as the logic could be different for the GPU architecture.
Instead, program_space::iterate_over_objfiles_in_search_order will be
responsible to delegate to the various solib_ops using a logic that is
yet to be determined.
I included this patch in this series (rather than the following one)
so that svr4_solib_ops::iterate_over_objfiles_in_search_order can access
svr4_solib_ops::default_debug_base, introduced in a later patch in this
series.
default_iterate_over_objfiles_in_search_order becomes the default
implementation of solib_ops::iterate_over_objfiles_in_search_order.
As far as I know, all architectures using
svr4_iterate_over_objfiles_in_search_order also use solib_ops_svr4, so I
don't expect this patch to cause behavior changes.
Change-Id: I71f8a800b8ce782ab973af2f2eb5fcfe4e06ec76
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Diffstat (limited to 'gdb/testsuite/gdb.python/py-read-memory-leak.py')
0 files changed, 0 insertions, 0 deletions