This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH v6 0/6] Remote fork events


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 are relatively few:
 * In patch 6, in the case of a 'kill' operation on a fork parent before
   follow_fork has been completed, implement killing the fork child on
   the host side instead of in gdbserver, and don't implement
   get_last_target_status in gdbserver.  In particular this fixes
   failures seen in gdb.base/disp-step-syscall.exp in previous versions
   of the patchset.

 * Eliminate a redundant assignment in
   gdbserver/linux-low.c:handle_extended_wait

 * Merge changes from mainline

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 before follow_fork is completed.

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:

  * Once vfork events are enabled, gdb.base/watch-vfork.exp
    shows PASS => FAIL in .sum diffs.  This test 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]