aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.fortran/pointer-to-pointer.f90
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2025-07-15 11:52:32 -0400
committerSimon Marchi <simon.marchi@efficios.com>2025-08-22 10:45:47 -0400
commitfbb487b4510dc2cd6cf7e82df062d7e40eeb8c27 (patch)
tree182a46a997ce1459329c1a0572a7568a300f2fc8 /gdb/testsuite/gdb.fortran/pointer-to-pointer.f90
parent77c87c12b3596567e4ac41b496cb4bac602d0dc3 (diff)
downloadgdb-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.fortran/pointer-to-pointer.f90')
0 files changed, 0 insertions, 0 deletions