diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-04-14 14:45:38 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2024-07-20 17:29:39 +0100 |
commit | b172d94b62b8a27c9d79cf70e565e31b21439c98 (patch) | |
tree | 5985e8b99af63ddfd875f0b5b01fc0e35b76396a /gdb/ppc-netbsd-tdep.c | |
parent | 7934cb137a779ca41123a673243027b1e6dd99e9 (diff) | |
download | binutils-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