[Bug threads/14618] gdbserver, scheduler-locking, thread exits and TARGET_WAITKIND_NO_RESUMED

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14618

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
The hangs themselves are now fixed on GDBserver mainline.

  https://sourceware.org/ml/gdb-patches/2014-02/msg00826.html

GDBserver's Linux core now knows about TARGET_WAITKIND_NO_RESUMED, but
I've left out adding that to the RSP ("[PATCH 5/5] Add
TARGET_WAITKIND_NO_RESUMED support to the RSP" at
https://sourceware.org/ml/gdb-patches/2014-01/msg00897.html), because I worried
about races in non-stop mode.

Assume N is the new stop reply for TARGET_WAITKIND_NO_RESUMED, like in the
patch above and say, the traffic goes like this:

(no thread was resumed before #1)

GDB sends two steps in a row.

 #1 -> vCont;s:555
 #2 <- OK

(555 exits)

 #3 <- %Stop:N   (no more resumed threads left)

 #4 -> vCont;s:666
 #5 <- OK

And now GDB goes and processes #3, and mistakenly believes no thread is left
running on the target, while in fact, 666 is left running.  Sounds like we need
something else in addition to TARGET_WAITKIND_NO_RESUMED, maybe thread exit
events (active only for stepped threads, by default, for efficiency).

I'll leave this open until this is fully sorted out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.