[PATCH v5 0/6] Remote fork events

[Don Breazeal <donb@codesourcery.com>]

This is an update to the patch series implementing remote follow-fork.
This update only implements fork and vfork events for extended remote,
omitting exec events and 'target remote' for now.

Changes from the previous version include:
 * Removed 'target remote' support, which is deferred for later.
 * Fixes per review comments, notably
   - issues with unpushing the target after detach or kill
   - reorganizing/renaming some things, both to match the
     native implementation better and for just plain better
     organization.
   - fixed and/or improved some of the event handling code.
 * Also added documentation to each individual patch, rather than
   saving it all for a subsequent 'documentation patch'.

The new series includes six patches as follows:

1/6: Preparatory patch that implements qSupported support for fork events
     and associated mechanisms.

2/6: Implements functions to clone breakpoint lists in gdbserver.

3/6: Implements follow fork for 'fork' but not 'vfork', for
     extended-remote targets only.

4/6: Adds the architecture-specific pieces of follow-fork that allows
     hardware watchpoints to be inherited by a forked child.
     This patch was previously approved, although I have added a
     trivial change to gdb/NEWS in this patch.

5/6: Adds follow fork for 'vfork'.

6/6: Adds catchpoints for 'fork' and 'vfork', along with support for
     killing a process that has forked but has not been followed.

TESTING:
Testing was mostly done using x86_64 Ubuntu, with the exception of the
architecture-specific patch, #4.  There are a few anomalies that show
up, but don't signify any problem.

 - Intermediate patches show failures due to the lack of features
   implemented in subsequent patches, like missing hardware watchpoint
   or catchpoint support.

 - Some vfork tests fail due to the lack of exec event support.

 - There are a couple of tests that show new failures that actually
   fail in the current mainline.  Details of these are as follows:

   * when vfork events are enabled, gdb.base/disp-step-syscall.exp
     shows PASS => FAIL in .sum diffs.  The test actually always
     fails.  With native/master, we see

      stepi^M
      FAIL: gdb.base/disp-step-syscall.exp: vfork: stepi vfork insn
(timeout)

     With remote and extended-remote/master, we see a bogus PASS result:
      stepi^M
      [Inferior 1 (process 9399) exited normally]^M
      (gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: stepi vfork insn

    The criteria to pass that test are pretty lax:
      gdb_test "stepi" ".*" "stepi $syscall insn"

  * Similarly, once vfork events are enabled, gdb.base/watch-vfork.exp
    shows PASS => FAIL in .sum diffs.  This test also always fails.  With
    native/master, we see this:

     continue^M
     Continuing.^M
     FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork
(sw) (timeout)

    With extended-remote/master, we see this:
     continue
     Continuing.
     [Inferior 1 (process 18866) exited normally]
     (gdb) FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after
vfork (sw) (the program exited)

    But once vfork events are enabled, we see:
     continue
     Continuing.
     Detaching from process 17405
     FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork
(sw) (timeout)
    which more-or-less matches the native/master behavior.

Thanks,
--Don