diff options
author | Pedro Alves <pedro@palves.net> | 2023-05-02 15:04:28 +0100 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2024-04-12 18:54:08 +0100 |
commit | c223d3738832011ced54e8415fa218934aebd0e4 (patch) | |
tree | d3b9fe1cadd701f5d4f4fcc1e82e3f719b86bc57 /bfd/version.h | |
parent | ec48903170926f3827144525b50ddd3c6ae3fbf0 (diff) | |
download | gdb-c223d3738832011ced54e8415fa218934aebd0e4.zip gdb-c223d3738832011ced54e8415fa218934aebd0e4.tar.gz gdb-c223d3738832011ced54e8415fa218934aebd0e4.tar.bz2 |
Fix setting watchpoints when current thread is running
Currently, when the current thread is running, you can print global
variables. However, if you try to set a watchpoint on the same
globals, GDB errors out, complaining that the selected thread is
running. Like so:
(gdb) c&
Continuing.
(gdb) p global
$1 = 1098377287
(gdb) watch global
Selected thread is running.
This patch makes setting the watchpoint work. You'll now get:
(gdb) c&
Continuing.
(gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)]
[New Thread 0x7ffff756d640 (LWP 434994)]
p global
$1 = 88168
(gdb) watch global
Hardware watchpoint 2: global
(gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)]
Thread 2 "function0" hit Hardware watchpoint 2: global
Old value = 185420
New value = 185423
int_return () at threads.c:39
39 }
The problem is that update_watchpoint calls get_selected_frame
unconditionally. We can skip it if the watchpoint expression is only
watching globals.
This adds a testcase that exercises both all-stop and non-stop, and
also software and hardware watchpoints. It is kfailed for software
watchpoints, as those require another fix not handled by this patch
(the sw watchpoint doesn't fire because GDB doesn't force the
running-free thread to switch to single-stepping).
Change-Id: I68ca948541aea3edd4f70741f272f543187abe40
Diffstat (limited to 'bfd/version.h')
0 files changed, 0 insertions, 0 deletions