[PATCH 0/3] Extended-remote follow-fork cleanups

Don Breazeal
2015-05-22T18:55:41Z

This patchset addresses a few extended-remote test failures discovered
by the buildbot and noted by Sergio in this email thread:

https://sourceware.org/ml/gdb-patches/2015-05/msg00372.html

Several of the failures were expected. These were in
gdb.base/foll-vfork.exp and depended on exec events, which are not yet
supported for extended-remote.

I had mistakenly concluded that a couple of other failures were due
to the lack of exec event support. One of these was due to the
remote interface printing a thread identifier instead of a process
identifier in the follow_fork verbose mode "Detaching..." messages.
The other was more serious, where a vfork child could sometimes be
(incorrectly) resumed when handling the vfork event.

The patchset addresses these three issues with the following three
patches:

Patch 1: modifies the ptids used in the verbose-mode "Detaching..."
messages in infrun.c:follow_fork_inferior to ensure that they print
"process nnn" instead of possibly "Thread nnn.nnn", so that native
and remote follow fork have the same behavior and match what the
follow fork tests expect.

Patch 2: initializes the threadinfo.last_resume_kind field for new
fork children in gdbserver/linux-low.c:handle_extended_wait. This
prevents the event handler from incorrectly resuming the child
if the stop event that is generated when it starts is reported
before the vfork event that initiated it.

Patch 3: disables the tests in gdb.base/foll-vfork.exp that depend
on exec event support for gdbserver targets.

Tested native, native-gdbserver, and native-extended-gdbserver on
x86_64 GNU/Linux.

Thanks
--Don