aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.cp/operator.cc
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2025-08-14 16:14:17 -0400
committerSimon Marchi <simon.marchi@efficios.com>2025-08-19 09:47:36 -0400
commit1d5f884e50590cc798fd33e9779f5d72c9d72f9c (patch)
tree89c0df8b28f0abdba6991b885a3da38f9d34ea16 /gdb/testsuite/gdb.cp/operator.cc
parent1bf1357c6827961386ef13462aed9d41221d5911 (diff)
downloadbinutils-1d5f884e50590cc798fd33e9779f5d72c9d72f9c.zip
binutils-1d5f884e50590cc798fd33e9779f5d72c9d72f9c.tar.gz
binutils-1d5f884e50590cc798fd33e9779f5d72c9d72f9c.tar.bz2
gdb: rename gdbarch_software_single_step -> gdbarch_get_next_pcs
I spotted this while reviewing a patch adding a new gdbarch_software_single_step implementation. I find the name "software_single_step" a bit misleading or unclear. It makes it sounds as if the function executed a single step. In reality, this function returns the possible next PCs for current instructions. We have a similar concept in GDBserver: linux_process_target::low_get_next_pcs. I like that name, it's clear and straight to the point. Rename gdbarch_software_single_step to gdbarch_get_next_pcs. I find this name more indicative of what happens. There is some code for ARM shared between GDB and GDBserver to implement both sides, also called "get next pcs", so I think it all fits well together. Tested by rebuilding. Change-Id: Ide74011a5034ba11117b7e7c865a093ef0b1dece Approved-by: Kevin Buettner <kevinb@redhat.com> Acked-by: Luis Machado <luis.machado.foss@gmail.com>
Diffstat (limited to 'gdb/testsuite/gdb.cp/operator.cc')
0 files changed, 0 insertions, 0 deletions