diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2023-11-17 19:55:58 +0000 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2023-11-17 20:01:35 +0000 |
commit | 7438771288f1acd5ab25277188a75ce9e48e256c (patch) | |
tree | 7f261a382ee420c2a26d6ed2f0f9305fb5285359 /gdb/i386-fbsd-tdep.c | |
parent | 4a2530397b87c66bd45b21cf20e2cc12bf26879f (diff) | |
download | fsf-binutils-gdb-7438771288f1acd5ab25277188a75ce9e48e256c.zip fsf-binutils-gdb-7438771288f1acd5ab25277188a75ce9e48e256c.tar.gz fsf-binutils-gdb-7438771288f1acd5ab25277188a75ce9e48e256c.tar.bz2 |
gdb: remove regcache's address space
While looking at the regcache code, I noticed that the address space
(passed to regcache when constructing it, and available through
regcache::aspace) wasn't relevant for the regcache itself. Callers of
regcache::aspace use that method because it appears to be a convenient
way of getting the address space for a thread, if you already have the
regcache. But there is always another way to get the address space, as
the callers pretty much always know which thread they are dealing with.
The regcache code itself doesn't use the address space.
This patch removes anything related to address_space from the regcache
code, and updates callers to get it from the thread in context. This
removes a bit of unnecessary complexity from the regcache code.
The current get_thread_arch_regcache function gets an address_space for
the given thread using the target_thread_address_space function (which
calls the target_ops::thread_address_space method). This suggest that
there might have been the intention of supporting per-thread address
spaces. But digging through the history, I did not find any such case.
Maybe this method was just added because we needed a way to get an
address space from a ptid (because constructing a regcache required an
address space), and this seemed like the right way to do it, I don't
know.
The only implementations of thread_address_space and
process_stratum_target::thread_address_space and
linux_nat_target::thread_address_space, which essentially just return
the inferior's address space. And thread_address_space is only used in
the current get_thread_arch_regcache, which gets removed. So, I think
that the thread_address_space target method can be removed, and we can
assume that it's fine to use the inferior's address space everywhere.
Callers of regcache::aspace are updated to get the address space from
the relevant inferior, either using some context they already know
about, or in last resort using the current global context.
So, to summarize:
- remove everything in regcache related to address spaces
- in particular, remove get_thread_arch_regcache, and rename
get_thread_arch_aspace_regcache to get_thread_arch_regcache
- remove target_ops::thread_address_space, and
target_thread_address_space
- adjust all users of regcache::aspace to get the address space another
way
Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7
Diffstat (limited to 'gdb/i386-fbsd-tdep.c')
-rw-r--r-- | gdb/i386-fbsd-tdep.c | 6 |
1 files changed, 2 insertions, 4 deletions
diff --git a/gdb/i386-fbsd-tdep.c b/gdb/i386-fbsd-tdep.c index f8c2758..58d06e3 100644 --- a/gdb/i386-fbsd-tdep.c +++ b/gdb/i386-fbsd-tdep.c @@ -354,10 +354,8 @@ static CORE_ADDR i386fbsd_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid, CORE_ADDR lm_addr, CORE_ADDR offset) { - struct regcache *regcache; - - regcache = get_thread_arch_regcache (current_inferior ()->process_target (), - ptid, gdbarch); + regcache *regcache + = get_thread_arch_regcache (current_inferior (), ptid, gdbarch); target_fetch_registers (regcache, I386_GSBASE_REGNUM); |