aboutsummaryrefslogtreecommitdiff
path: root/configure
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2024-05-07 13:57:47 +0100
committerPedro Alves <pedro@palves.net>2024-05-17 20:14:26 +0100
commit7d6c04c5807753e5ad485eea6f4ce0946d4f1443 (patch)
tree631bdc886e4a9ecc2ad0c4183645377b671a0f3e /configure
parent650daf18185de6d2e51da2fe5cd0b94cc7fb9174 (diff)
downloadbinutils-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 'configure')
0 files changed, 0 insertions, 0 deletions