From d9d41e786a077db1b536b1124af6e135b9ad46a0 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 3 Feb 2015 16:07:53 +0100 Subject: [PATCH] Fix up some target is-async vs can-async confusions In all these cases we're interested in whether the target is currently async, with its event sources installed in the event loop, not whether it can async if needed. Also, I'm not seeing the point of the target_async call from within linux_nat_wait. That's normally done on resume instead, which this target already does. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2015-02-03 Pedro Alves * linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use target_is_async_p instead of target_can_async. (linux_nat_wait): Use target_is_async_p instead of target_can_async. Don't enable async here. * remote.c (interrupt_query, remote_wait, putpkt_binary): Use target_is_async_p instead of target_can_async. --- gdb/ChangeLog | 9 +++++++++ gdb/linux-nat.c | 16 ++++++---------- gdb/remote.c | 6 +++--- 3 files changed, 18 insertions(+), 13 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 1109753..e7e60bb 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,12 @@ +2015-02-03 Pedro Alves + + * linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use + target_is_async_p instead of target_can_async. + (linux_nat_wait): Use target_is_async_p instead of + target_can_async. Don't enable async here. + * remote.c (interrupt_query, remote_wait, putpkt_binary): Use + target_is_async_p instead of target_can_async. + 2015-02-02 Simon Marchi * varobj.h (lang_varobj_ops): Mention which return values need diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index b49cd57..b4893d44 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -520,7 +520,7 @@ linux_child_follow_fork (struct target_ops *ops, int follow_child, /* If we're in async mode, need to tell the event loop there's something here to process. */ - if (target_can_async_p ()) + if (target_is_async_p ()) async_file_mark (); } } @@ -3222,7 +3222,7 @@ linux_nat_wait_1 (struct target_ops *ops, target_pid_to_str (lp->ptid)); } - if (!target_can_async_p ()) + if (!target_is_async_p ()) { /* Causes SIGINT to be passed on to the attached process. */ set_sigint_trap (); @@ -3293,7 +3293,7 @@ linux_nat_wait_1 (struct target_ops *ops, ourstatus->kind = TARGET_WAITKIND_NO_RESUMED; - if (!target_can_async_p ()) + if (!target_is_async_p ()) clear_sigint_trap (); restore_child_signals_mask (&prev_mask); @@ -3321,7 +3321,7 @@ linux_nat_wait_1 (struct target_ops *ops, sigsuspend (&suspend_mask); } - if (!target_can_async_p ()) + if (!target_is_async_p ()) clear_sigint_trap (); gdb_assert (lp); @@ -3479,7 +3479,7 @@ linux_nat_wait (struct target_ops *ops, } /* Flush the async file first. */ - if (target_can_async_p ()) + if (target_is_async_p ()) async_file_flush (); /* Resume LWPs that are currently stopped without any pending status @@ -3497,16 +3497,12 @@ linux_nat_wait (struct target_ops *ops, /* If we requested any event, and something came out, assume there may be more. If we requested a specific lwp or process, also assume there may be more. */ - if (target_can_async_p () + if (target_is_async_p () && ((ourstatus->kind != TARGET_WAITKIND_IGNORE && ourstatus->kind != TARGET_WAITKIND_NO_RESUMED) || !ptid_equal (ptid, minus_one_ptid))) async_file_mark (); - /* Get ready for the next event. */ - if (target_can_async_p ()) - target_async (inferior_event_handler, 0); - return event_ptid; } diff --git a/gdb/remote.c b/gdb/remote.c index c4d09ba..9be15cb 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -5079,7 +5079,7 @@ interrupt_query (void) { target_terminal_ours (); - if (target_can_async_p ()) + if (target_is_async_p ()) { signal (SIGINT, handle_sigint); quit (); @@ -6036,7 +6036,7 @@ remote_wait (struct target_ops *ops, else event_ptid = remote_wait_as (ptid, status, options); - if (target_can_async_p ()) + if (target_is_async_p ()) { /* If there are are events left in the queue tell the event loop to return here. */ @@ -7226,7 +7226,7 @@ putpkt_binary (const char *buf, int cnt) case it's not possible to issue a command while the target is running. This is not a problem in non-stop mode, because in that case, the stub is always ready to process serial input. */ - if (!non_stop && target_can_async_p () && rs->waiting_for_stop_reply) + if (!non_stop && target_is_async_p () && rs->waiting_for_stop_reply) { error (_("Cannot execute this command while the target is running.\n" "Use the \"interrupt\" command to stop the target\n" -- 2.7.4