Test results for commit afa8d396f6a952d17b348a981dd2c56f83305611 on branch master

[sergiodj at redhat dot com]

*** TEST RESULTS FOR COMMIT afa8d396f6a952d17b348a981dd2c56f83305611 ***

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

fix gdbserver/linux-low'c's pending status handling
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.