This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH v4 0/7] Remote fork events
- From: "Breazeal, Don" <donb at codesourcery dot com>
- To: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Sun, 25 Jan 2015 13:58:10 -0800
- Subject: [PATCH v4 0/7] Remote fork events
- Authentication-results: sourceware.org; auth=none
- References: <201501252151 dot t0PLo3jE018308 at mx0b-0013c101 dot pphosted dot com>
From: Don Breazeal <donb@codesourcery.com>
Subject: [PATCH v4 0/7] Remote fork events
In-Reply-To: <54C236B9.8060200@redhat.com>
This is an update to the patch series implementing remote follow-fork.
This update only implements fork and vfork events, omitting exec events
for now.
The series has been renumbered, since the numbering of the original patch
series has little relevance now. Let me know if I should maintain the
original numbering.
The primary difference between this series and previous versions is that
it includes support for 'target remote' as well as extended-remote. It
also eliminates the vFollowFork packet used in previous versions and uses
the qSupported packet to determine if fork events are supported by
gdbserver.
The new series includes seven patches as follows:
1/7: Preparatory patch that implements qSupported support for fork events
and associated mechanisms.
2/7: Implements functions to clone breakpoint lists in gdbserver.
3/7: Implements follow fork for 'fork' but not 'vfork' and for
extended-remote
targets only. Note subject line was garbled, see ERRATA below.
4/7: Extends follow fork for 'fork' to 'target remote' as well as
extended-remote.
5/7: Adds the architecture-specific pieces of follow-fork that allows
hardware watchpoints to be inherited by a forked child.
6/7: Adds follow fork for 'vfork'.
7/7: Adds catchpoints for 'fork' and 'vfork', along with support for
killing a process that has forked but has not been followed.
ERRATA:
I have to apologize in advance for a few minor formatting and coding
errors, listed below. I decided that these were trivial enough that
they didn't warrant the delay required to go through the whole rebase/test
cycle. The issues are:
4/7: in linux-low.c there is a blank line containing spaces.
4/7: in remote.c, I left a /* XXX */ comment.
4/7: in remote.c there is an unnecessary static declaration of
extended_remote_kill
The subject line of patch 3 was garbled somehow. Sent on 25-Jan-2015,
it reads "Re: [PATCH v4 3/7 v3] Extended-remote Linux follow fork" when
it should read "[PATCH v4 3/7] Extended-remote-Linux follow fork". My
incompetent use of --in-reply-to with git send-email, I'm sure.
TESTING:
Testing was mostly done using x86_64 Ubuntu, with the exception of the
architecture-specific patch, #5. 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