diff options
author | Pedro Alves <pedro@palves.net> | 2023-05-09 10:13:08 +0100 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2024-05-08 00:39:55 +0100 |
commit | b67852992bcd4e14af9f1b6eff3b8500308352c9 (patch) | |
tree | 55e2170f724755bd1de1a58ee669e6aecd2c8f70 /gdbserver | |
parent | c151e663fad2297d1cf21ce4e4143dc5a3eb0f96 (diff) | |
download | fsf-binutils-gdb-b67852992bcd4e14af9f1b6eff3b8500308352c9.zip fsf-binutils-gdb-b67852992bcd4e14af9f1b6eff3b8500308352c9.tar.gz fsf-binutils-gdb-b67852992bcd4e14af9f1b6eff3b8500308352c9.tar.bz2 |
Windows gdb+gdbserver: Eliminate DONT_SUSPEND
There's a single call to thread_rec(DONT_SUSPEND), in
windows_process_info::handle_exception.
In GDB, the windows-nat.c thread_rec implementation avoids actually
calling SuspendThread on the event thread by doing:
th->suspended = -1;
I am not exactly sure why, but it kind of looks like it is done as an
optimization, avoiding a SuspendThread call? It is probably done for
the same reason as the code touched in the previous patch avoided
suspending the event thread.
This however gets in the way of non-stop mode, which will really want
to SuspendThread the event thread for DBG_REPLY_LATER.
In gdbserver's thread_rec implementation DONT_SUSPEND is ignored, and
thread_rec actually always suspends, which really suggests that
SuspendThread on the event thread is really not a problem. I really
can't imagine why it would be.
DONT_SUSPEND invalidates the thread's context, but there is no need to
invalidate the context when we get an event for a thread, because we
invalidate it when we previously resumed the thread.
So, we can just remove the thread_rec call from
windows_process_info::handle_exception. That's what this patch does.
Change-Id: I0f328542bda6d8268814ca1ee4ae7a478098ecf2
Diffstat (limited to 'gdbserver')
0 files changed, 0 insertions, 0 deletions