[binutils-gdb] gdbserver/Linux: unbreak non-stop

[sergiodj+buildbot at redhat dot com]

*** TEST RESULTS FOR COMMIT 91baf43fa70827325272667c8e7a86c553c767dc ***

Author: Pedro Alves <palves@redhat.com>
Branch: master
Commit: 91baf43fa70827325272667c8e7a86c553c767dc

gdbserver/Linux: unbreak non-stop
The previous change added an assertion that is catching yet another
bug in count_events_callback/select_event_lwp_callback:

  (gdb)
  PASS: gdb.mi/mi-nonstop.exp: interrupted
  mi_expect_interrupt: expecting: \*stopped,(reason="signal-received",signal-name="0",signal-meaning="Signal 0"|reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt")[^
  ]*

  /home/pedro/gdb/mygit/src/gdb/gdbserver/linux-low.c:2329: A problem internal to GDBserver has been detected.
  select_event_lwp: Assertion `num_events > 0' failed.
  =thread-group-exited,id="i1"

Certainly select_event_lwp_callback should always at least find one
event, as it's only called because an event triggered (though we may
have more than one: the point of the function is randomly picking
one).

An LWP that GDB previously asked to continue/step (thus is resumed)
and gets a vCont;t request ends up with last_resume_kind ==
resume_stop.  These functions in gdbserver used to filter out events
that weren't going to be reported to GDB; I think the last_resume_kind
kind check used to make sense at that point, but it no longer does.

gdb/gdbserver/ChangeLog:
2015-03-19  Pedro Alves  <palves@redhat.com>

	* linux-low.c (count_events_callback, select_event_lwp_callback):
	No longer check whether the thread has resume_stop as last resume
	kind.