diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2025-08-14 16:14:17 -0400 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2025-08-19 09:47:36 -0400 |
commit | 1d5f884e50590cc798fd33e9779f5d72c9d72f9c (patch) | |
tree | 89c0df8b28f0abdba6991b885a3da38f9d34ea16 /gdb/testsuite/gdb.cp/operator.cc | |
parent | 1bf1357c6827961386ef13462aed9d41221d5911 (diff) | |
download | binutils-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