Fix up some target is-async vs can-async confusions
authorPedro Alves <palves@redhat.com>
Tue, 3 Feb 2015 15:07:53 +0000 (16:07 +0100)
committerPedro Alves <palves@redhat.com>
Tue, 3 Feb 2015 15:07:53 +0000 (16:07 +0100)
commitd9d41e786a077db1b536b1124af6e135b9ad46a0
tree1eb216b087ea45fdaf784700d4f6e04e5aa25558
parent64d2901806c171c0d949f8fb1b29b4e5ba8cf04d
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  <palves@redhat.com>

* 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
gdb/linux-nat.c
gdb/remote.c