gdbserver/Linux: unbreak non-stop
authorPedro Alves <palves@redhat.com>
Thu, 19 Mar 2015 16:51:09 +0000 (16:51 +0000)
committerPedro Alves <palves@redhat.com>
Thu, 19 Mar 2015 16:51:09 +0000 (16:51 +0000)
commit91baf43fa70827325272667c8e7a86c553c767dc
treed86ff0e50c86c20bbde2a6c0d28f32da40fe6e09
parent1740ba0cec44bdfe9cba586892a5953a4c602228
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.
gdb/gdbserver/ChangeLog
gdb/gdbserver/linux-low.c