From f7bf4732bb5a8d2b27c3ab7428f359481cffe970 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Sat, 4 Jul 2020 19:31:21 +0100 Subject: Avoid constant stream of TARGET_WAITKIND_NO_RESUMED 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. --- gdb/infrun.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gdb/infrun.c b/gdb/infrun.c index 6b655d4..a01e096 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -8116,7 +8116,11 @@ prepare_to_wait (struct execution_control_state *ecs) 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 (); } -- cgit v1.1