aboutsummaryrefslogtreecommitdiff
path: root/gdb/aarch64-fbsd-tdep.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2023-11-17 19:55:58 +0000
committerSimon Marchi <simon.marchi@efficios.com>2023-11-17 20:01:35 +0000
commit7438771288f1acd5ab25277188a75ce9e48e256c (patch)
tree7f261a382ee420c2a26d6ed2f0f9305fb5285359 /gdb/aarch64-fbsd-tdep.c
parent4a2530397b87c66bd45b21cf20e2cc12bf26879f (diff)
downloadgdb-7438771288f1acd5ab25277188a75ce9e48e256c.zip
gdb-7438771288f1acd5ab25277188a75ce9e48e256c.tar.gz
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/aarch64-fbsd-tdep.c')
-rw-r--r--gdb/aarch64-fbsd-tdep.c3
1 files changed, 1 insertions, 2 deletions
diff --git a/gdb/aarch64-fbsd-tdep.c b/gdb/aarch64-fbsd-tdep.c
index 1102eb0..681149b 100644
--- a/gdb/aarch64-fbsd-tdep.c
+++ b/gdb/aarch64-fbsd-tdep.c
@@ -215,8 +215,7 @@ aarch64_fbsd_get_thread_local_address (struct gdbarch *gdbarch, ptid_t ptid,
aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
struct regcache *regcache;
- regcache = get_thread_arch_regcache (current_inferior ()->process_target (),
- ptid, gdbarch);
+ regcache = get_thread_arch_regcache (current_inferior (), ptid, gdbarch);
target_fetch_registers (regcache, tdep->tls_regnum_base);