aboutsummaryrefslogtreecommitdiff
path: root/gdb/ppc-netbsd-tdep.c
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-04-14 14:45:38 +0100
committerAndrew Burgess <aburgess@redhat.com>2024-07-20 17:29:39 +0100
commitb172d94b62b8a27c9d79cf70e565e31b21439c98 (patch)
tree5985e8b99af63ddfd875f0b5b01fc0e35b76396a /gdb/ppc-netbsd-tdep.c
parent7934cb137a779ca41123a673243027b1e6dd99e9 (diff)
downloadbinutils-b172d94b62b8a27c9d79cf70e565e31b21439c98.zip
binutils-b172d94b62b8a27c9d79cf70e565e31b21439c98.tar.gz
binutils-b172d94b62b8a27c9d79cf70e565e31b21439c98.tar.bz2
gdb: remove breakpoint_re_set_one
During a later patch I wanted to reset a single breakpoint, so I called breakpoint_re_set_one. However, this is not the right thing to do. If we look at breakpoint_re_set then we see that there's a whole bunch of state that needs to be preserved prior to calling breakpoint_re_set_one, and after calling breakpoint_re_set_one we still need to call update_global_location_list. I could just update the comment on breakpoint_re_set_one to make it clearer how the function should be used -- or more likely to warn that the function should only be used as a helper from breakpoint_re_set. However, breakpoint_re_set_one is only 3 lines long. So I figure it might actually be easier to just fold breakpoint_re_set_one into breakpoint_re_set, then there's no risk of accidentally calling breakpoint_re_set_one when we shouldn't. There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/ppc-netbsd-tdep.c')
0 files changed, 0 insertions, 0 deletions