diff options
author | Pedro Alves <pedro@palves.net> | 2024-05-07 13:57:47 +0100 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2024-05-17 20:14:26 +0100 |
commit | 7d6c04c5807753e5ad485eea6f4ce0946d4f1443 (patch) | |
tree | 631bdc886e4a9ecc2ad0c4183645377b671a0f3e /gdbsupport/selftest.cc | |
parent | 650daf18185de6d2e51da2fe5cd0b94cc7fb9174 (diff) | |
download | binutils-7d6c04c5807753e5ad485eea6f4ce0946d4f1443.zip binutils-7d6c04c5807753e5ad485eea6f4ce0946d4f1443.tar.gz binutils-7d6c04c5807753e5ad485eea6f4ce0946d4f1443.tar.bz2 |
Windows gdb: Watchpoints while running (internal vs external stops)
Teach the Windows target to temporarily pause all threads when we
change the debug registers for a watchpoint. Implements the same
logic as Linux uses:
~~~
/* (...) if threads are running when the
mirror changes, a temporary and transparent stop on all threads
is forced so they can get their copy of the debug registers
updated on re-resume. (...) */
~~~
On Linux, we send each thread a SIGSTOP to step them. On Windows,
SuspendThread itself doesn't cause any asynchronous debug event to be
reported. However, we've implemented windows_nat_target::stop such
that it uses SuspendThread, and then queues a pending GDB_SIGNAL_0
stop on the thread. That results in a user-visible stop, while here
we want a non-user-visible stop. So what we do is re-use that
windows_nat_target::stop stopping mechanism, but add an external vs
internal stopping kind distinction. An internal stop results in
windows_nat_target::wait immediately re-resuming the thread.
Note we don't make the debug registers poking code SuspendThread ->
write debug registers -> ContinueThread itself, because SuspendThread
is actually asynchronous and may take a bit to stop the thread (a
following GetThreadContext blocks until the thread is actually
suspended), and, there will be several debug register writes when a
watchpoint is set, because we have to set all of DR0, DR1, DR2, DR3,
and DR7. Defering the actualy writes to ::wait avoids a bunch of
SuspendThread/ResumeThread sequences, so in principle should be
faster.
Change-Id: I39c2492c7aac06d23ef8f287f4afe3747b7bc53f
Diffstat (limited to 'gdbsupport/selftest.cc')
0 files changed, 0 insertions, 0 deletions