Another fix I'm working made schedlock.exp fail with gdbserver
frequently. Looking deeper, it turns out to be a pre-existing bug.
status_pending_p_callback is filtering out LWPs incorrectly. The
result is that that sometimes status_pending_p_callback returns a
pending event for an LWP that isn't expected, and then GDBserver gets
very confused.
E.g,. when doing a step-over, linux_wait_for_event is called with a
particular LWP's ptid, meaning events for all other LWPs should be
left pending, but here we see it retuning an event for some other LWP:
linux_wait_1: [<all threads>]
step_over_bkpt set [LWP 29577.29577], doing a blocking wait <--------
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x80000001): status(57f), 0
LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
pc is 0x4007a0
src/gdb/gdbserver/linux-low.c:2587: A problem internal to GDBserver has been detected.
linux_wait_1: got event for 29581 <--------
Remote connection closed
(gdb) FAIL: gdb.threads/schedlock.exp: continue to breakpoint: return to loop (initial)
delete breakpoints
Tested on x86_64 Fedora 20.
gdb/gdbserver/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* linux-low.c (status_pending_p_callback): Use ptid_match.
+2015-02-20 Pedro Alves <palves@redhat.com>
+
+ * linux-low.c (status_pending_p_callback): Use ptid_match.
+
2015-02-19 Antoine Tremblay <antoine.tremblay@ericsson.com>
PR breakpoints/16812
ptid_t ptid = * (ptid_t *) arg;
/* Check if we're only interested in events from a specific process
- or its lwps. */
- if (!ptid_equal (minus_one_ptid, ptid)
- && ptid_get_pid (ptid) != ptid_get_pid (thread->entry.id))
+ or a specific LWP. */
+ if (!ptid_match (ptid_of (thread), ptid))
return 0;
if (lp->status_pending_p