If we hit the synchronous execution command case described by
handle_no_resumed, and handle_no_resumed determines that the event
should be ignored, because it found a thread that is executing, we end
up in prepare_to_wait.
There, if the current target is not registered in the event loop right
now, we call mark_infrun_async_event_handler. With that event handler
marked, the event loop calls again into fetch_inferior_event, which
calls target_wait, which returns TARGET_WAITKIND_NO_RESUMED, and we
end up in handle_no_resumed, again ignoring the event and marking
infrun_async_event_handler. The result is that GDB is now always
keeping the CPU 100% busy in this loop, even though it continues to be
able to react to input and to real target events, because we still go
through the event-loop.
The problem is that marking of the infrun_async_event_handler in
prepare_to_wait. That is there to handle targets that don't support
asynchronous execution. So the correct predicate is whether async
execution is supported, not whether the target is async right now.
gdb/ChangeLog:
PR gdb/26199
* infrun.c (prepare_to_wait): Check target_can_async_p instead of
target_is_async_p.
+2020-07-10 Pedro Alves <pedro@palves.net>
+
+ PR gdb/26199
+ * infrun.c (prepare_to_wait): Check target_can_async_p instead of
+ target_is_async_p.
+
2020-07-10 Pedro Alves <pedro@palves.net>
PR gdb/26199
ecs->wait_some_more = 1;
- if (!target_is_async_p ())
+ /* If the target can't async, emulate it by marking the infrun event
+ handler such that as soon as we get back to the event-loop, we
+ immediately end up in fetch_inferior_event again calling
+ target_wait. */
+ if (!target_can_async_p ())
mark_infrun_async_event_handler ();
}