diff options
author | Hannes Domani <ssbssa@yahoo.de> | 2023-12-06 13:45:51 +0100 |
---|---|---|
committer | Hannes Domani <ssbssa@yahoo.de> | 2023-12-06 13:45:59 +0100 |
commit | 288363c1737f93e2f7cb8c06026c11a5ff77fb58 (patch) | |
tree | ad450c4c17badd3f0243a3a5303920aedebab0de /sim | |
parent | 5a22e042e41db962cd6a79cd59cab46cbbe58a98 (diff) | |
download | binutils-288363c1737f93e2f7cb8c06026c11a5ff77fb58.zip binutils-288363c1737f93e2f7cb8c06026c11a5ff77fb58.tar.gz binutils-288363c1737f93e2f7cb8c06026c11a5ff77fb58.tar.bz2 |
Fix hardware watchpoints in replay mode
Changes introduced by commit 9e8915c6cee5c37637521b424d723e990e06d597
caused a regression that meant hardware watchpoint stops would not
trigger in reverse execution or replay mode. This was documented in
PR breakpoints/21969.
The problem is that record_check_stopped_by_breakpoint always overwrites
record_full_stop_reason, thus loosing the TARGET_STOPPED_BY_WATCHPOINT
value which would be checked afterwards.
This commit fixes that by not overwriting the stop-reason in
record_full_stop_reason if we're not stopped at a breakpoint.
And the test for hw watchpoints in gdb.reverse/watch-reverse.exp actually
tested sw watchpoints again, since "set can-use-hw-watchpoints 1"
doesn't convert enabled watchpoints to use hardware.
This is fixed by disabling said watchpoint while enabling hw watchpoints.
The same is not done for gdb.reverse/watch-precsave.exp, since it's not
possible to use hw watchpoints in restored recordings anyways.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21969
Approved-by: Guinevere Larsen <blarsen@redhat.com>
Diffstat (limited to 'sim')
0 files changed, 0 insertions, 0 deletions