[PATCH 00/16 v3] Linux extended-remote fork and exec events

Don Breazeal
2014-10-31T23:29:07Z

This is an update to the patch series implementing fork and exec events
for extended-remote Linux targets. The updates include changes requested
by Pedro for patches 4 and 5, plus minor changes throughout to catch up
to changes made upstream since the last version of this series was posted.
The most significant of those changes were related to upstream refactoring
that changed names from "xxx_inferior" to "xxx_thread".

Patch 4 was rewritten to use qSupported as the mechanism for determining
which extended-mode-only events are supported by gdbserver, instead of
using a new packet for this.

Patch 5 received a little refactoring and polishing.

Patches 1-3 have been approved and pushed, so they aren't included.

Patches 10 and 15 were approved by Eli some time ago, but are still
included here since they haven't been pushed.

Thanks,
--Don

====================================================================

This patch series implements fork and exec events for extended-remote linux
targets. Features that are enabled include:

* follow-fork-mode
* detach-on-fork
* follow-exec-mode
* catch fork/vfork/exec

This work addresses PR gdb/13584, and is part of the local/remote debugging
feature parity project
(https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity).

My patch v2 test results showed the following changes:

* native: PASS +46
- this is due the addition of non-stop mode tests to
gdb.threads/non-ldr-exc-*.exp.

* remote: no change

* extended-remote: PASS: +329, FAIL: -134, KFAIL: +1,
UNTESTED: +8, UNSUPPORTED: -6

Some items to note about the extended-remote results:

- there are some extended-remote failures in
gdb.base/disp-step-syscall.exp that don't show up in the unmodified
version on the native target. Investigation shows that these tests
are producing a bogus PASS result on the native target. I did not
pursue this further.

- the new non-stop tests in gdb.threads/non-ldr-exc-*.exp give an
UNTESTED result for extended-remote. This is due to an RSP
error in non-stop mode when running to main. I spent some time
investigating this and concluded that I should leave it alone for now,
for fear of having an ever-growing, never-ending project. My plan is
to track this with a bug report once that is appropriate.

- gdb.threads/thread-execl.exp gives a couple of failures related to
scheduler locking. As with the previous item, after spending some
time on this I concluded that pursuing it further now would be
feature-creep, and that this should be tracked with a bug report.

- gdb.trace/tspeed.exp got some timeout failures one time, but I
was unable to reproduce it. I'm unsure whether this is significant.

I can provide test logs or .sum diffs if anybody is interested in
specifics.

The contents of the patch series are as follows:

Patch 1: refactor native follow-fork implementation to move
target-independent code from target-dependent file (linux-nat.c)
to make it useful for extended-remote targets.

Patch 2: encapsulate the code used to print verbose/debug messages
related to folow-fork into functions, and add a message in one case.
Also make messages distinguish between fork and vfork.

Patch 3: encapsulate code that identifies and extracts extended
ptrace events found in the Linux wait status into functions, and call
them everywhere that the hard-coded wait status processing was used.

Patch 4: implements a mechanism for determining what extended-mode
features gdbserver supports. There are several issues that this addresses,
which are detailed in the patch 4 description. Basically, the patch
adds some new items to the qSupported response denoting extended-mode-only
event support, and defines new packets to represent those features. In
gdbserver, it splits checking whether the OS supports the features from
actually enabling them, and enables them only when it is clear that
extended mode is active.

Patch 5: implements some functions to clone the breakpoint lists in
gdbserver. These are needed because in gdbserver, each process maintains a
separate breakpoint list. When a fork occurs, the child process needs a
copy of the parent's breakpoint list so that it can manage the breakpoints
using existing mechanisms in gdbserver.

Patch 6: implements follow-fork, but only for 'fork', not 'vfork'. I split
these apart in an attempt to keep the size of the patches down to a
reviewable size.

Patch 7: adds the architecture-specific pieces of follow-fork. This is the
mechanism that handles copying the debug register state from the parent to
the child.

Patch 8: adds follow-fork for vfork.

Patch 9: adds 'catch fork' and 'catch vfork', along with some code to make
sure that killing a process that has forked, but before the fork is
followed, also kills the child process.

Patch 10: implements changes to the manual and the NEWS file for the fork
event changes.

Patch 11: implements support for the extended ptrace event
PTRACE_EVENT_EXIT, which is a prerequisite for the exec event support.

Patch 12: implements exec event support and follow-exec.

Patch 13: implements exec catchpoints.

Patch 14: suppresses some spurious warnings that were generated after
an exec. These warnings were caused when gdbserver attempted to check
the version number from the r_debug structure in the new image before
the structure had been initialized.

Patch 15: implements changed to the manual and NEWS file for the exec
event changes.

Patch 16: changes how gdb.base/foll-exec.exp starts GDB and loads the
program so that it will work with extended-remote. It also extends the
tests gdb.threads/non-ldr-exc-[1-4].exp to test in non-stop mode as well as
in all-stop mode.

thanks
--Don