binutils-gdb

Debugging with "maintenance set target-async off" on Linux has been
broken since 5b6d1e4f ("Multi-target support").

The issue is easy to reproduce:

    $ ./gdb -q --data-directory=data-directory -nx ./test
    Reading symbols from ./test...
    (gdb) maintenance set target-async off
    (gdb) start
    Temporary breakpoint 1 at 0x1151: file test.c, line 5.
    Starting program: /home/simark/build/binutils-gdb/gdb/test

... and it hangs there.

The difference between pre-5b6d1e4f and 5b6d1e4f is that
fetch_inferior_event now calls target_wait with TARGET_WNOHANG for
non-async-capable targets, whereas it didn't before.

For non-async-capable targets, this is how it's expected to work when
resuming execution:

1. we call resume
2. the infrun async handler is marked in prepare_to_wait, to immediately
   wake up the event loop when we get back to it
3. fetch_inferior_event calls the target's wait method without
   TARGET_WNOHANG, effectively blocking until the target has something
   to report

However, since we call the target's wait method with TARGET_WNOHANG,
this happens:

1. we call resume
2. the infrun async handler is marked in prepare_to_wait, to immediately
   wake up the event loop when we get back to it
3. fetch_inferior_event calls the target's wait method with
   TARGET_WNOHANG, the target has nothing to report yet
4. we go back to blocking on the event loop
5. SIGCHLD finally arrives, but the event loop is not woken up, because
   we are not in async mode.  Normally, we should have been stuck in
   waitpid the SIGCHLD would have unblocked us.

We end up in this situation because these two necessary conditions are
met:

1. GDB uses the TARGET_WNOHANG option with a target that can't do async.
   I don't think this makes sense.  I mean, it's technically possible,
   the doc for TARGET_WNOHANG is:

  /* Return immediately if there's no event already queued.  If this
     options is not requested, target_wait blocks waiting for an
     event.  */
  TARGET_WNOHANG = 1,

   ... which isn't in itself necessarily incompatible with synchronous
   targets.  It could be possible for a target to support non-blocking
   polls, while not having a way to asynchronously wake up the event
   loop, which is also necessary to support async.  But as of today,
   we don't expect GDB and sync targets to work this way.

2. The linux-nat target, even in the mode where it emulates a
   synchronous target (with "maintenance set target-async off") respects
   TARGET_WNOHANG.  Other non-async targets, such as windows_nat_target,
   simply don't check / support TARGET_WNOHANG, so their wait method is
   always blocking.

Fix the first issue by avoiding using TARGET_WNOHANG on non-async
targets, in do_target_wait_1.  Add an assert in target_wait to verify it
doesn't happen.

The new test gdb.base/maint-target-async-off.exp is a simple test that
just tries running to main and then to the end of the program, with
"maintenance set target-async off".

gdb/ChangeLog:

	PR gdb/26642
	* infrun.c (do_target_wait_1): Clear TARGET_WNOHANG if the
	target can't do async.
	* target.c (target_wait): Assert that we don't pass
	TARGET_WNOHANG to a target that can't async.

gdb/testsuite/ChangeLog:

	PR gdb/26642
	* gdb.base/maint-target-async-off.c: New test.
	* gdb.base/maint-target-async-off.exp: New test.

Change-Id: I69ad3a14598863d21338a8c4e78700a58ce7ad86