Feature Parity: Remote fork following

[Luis Machado <lgustavo@codesourcery.com>]

Hi,

One of the things that exists in the feature parity wish list
(http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity) is remote fork
following. I'm volunteering for that work. I came up with the following 
draft and i thought i'd make it available for discussion so we can all 
agree upon a good enough design.

Remote fork following is currently available only for native targets. In 
order to expand this feature to remote targets, we need remote protocol 
changes.

First, we have two remote modes (remote and extended-remote). remote is 
only capable of debugging a single process at a time. extended-remote is 
capable of debugging multiple processes, so it looks like the best fit 
for this feature.

Though extended-remote is the right protocol to deal with remote 
fork/vfork events, we may still want to consider a fallback mechanism 
for the single-process remote protocol.

Consider a process P1, with Px being its childs. The possible variations 
we have are:


follow-fork-mode parent
detach-on-fork on.
---
- P1 forks P2
- P1 continues under gdb's control and is moved outside of the fork call.
- P2 is detached from gdb and runs freely.


follow-fork-mode parent
detach-on-fork off.
---
- P1 forks P2
- P1 continues under gdb's control and is moved outside of the fork call.
- P2 is added to the list of debugged processes and is left sitting at 
the fork call.
- GDB controls both P1 and P2


follow-fork-mode child
detach-on-fork on.
---
- P1 forks P2
- P1 is detached from gdb and runs freely.
- P2 is added to the list of debugged processes and is moved outside of 
the fork call.


follow-fork-mode child
detach-on-fork off.
---
- P1 forks P2
- P1 is left sitting at the fork call.
- P2 is added to the list of debugged processes and runs freely under 
GDB's control.


Remote protocol changes
-----------------------

In order to inform gdbserver of the fork-handling settings, we need a 
couple new packets and one additional feature query string.

qFollowForkMode:n - Sets the fork-following behavior for the remote side.
n is 0 - Follow parent
n is 1 - Follow child

qDetachOnFork:n - Sets whether the remote stub should detach the 
child/parent on a fork (depends on whether it is following the parent or 
the child).
n is 0 - Do not detach child on fork
n is 1 - Detach child on fork

FollowFork+ - If the remote side adsertises support for this feature it 
means both qFollowForkMode and qDetachOnFork packets are supported and 
can be issued by GDB to configure the behavior on the remote stub. The 
default settings are Follow Parent and Detach on fork.

With the changes above we have a way of configuring the remote stub to 
handle fork events properly, but we still need a way to inform GDB of a 
fork event since this information comes from PTRACE.

The simplest way to inform GDB of such event is through the usual stop 
reply packet T, via the stop reason field. For our purposes we add a 
couple new stop reasons: fork and vfork. Those should accompany the 
reply and let GDB know that either a fork or vfork took place. Maybe we 
should also add a execd reason for future use?

Stop Reply Packet T will be augmented to reply the following stop reasons:

T AA fork... - The packet indicates that a fork has happened in the 
program being debugged.
T AA vfork... - The packet indicates that a vfork has happened in the 
program being debugged.
T AA execd... - The packet indicates that the inferior execd a new image 
(TBD)

With the protocol extended and considering gdbserver's event loop is 
ready to handle and report fork events, we need to define the control 
flow. Two scenarios come to mind:

A - GDB has less control over the remote stub and the stub is clever 
enough to decide what to do and report back to GDB (suitable for 
all-stop mode?).
B - GDB has more control over the remote stub and the stub mainly 
reports the fork event back to GDB for it to decide what to do. GDB will 
then proceed to guide the stub/program through the
correct forking process and behavior (suitable for non-stop due to 
displaced stepping and software single-stepping?).

Control flow A

- GDB connects to the stub and checks the availability of FollowFork+.
- GDB sends the settings for FollowForkMode and DetachOnFork to the stub 
on connection startup or whenever these settings change.
- The stub runs the program (continue or step) and eventually notices it 
forked (fork or vfork).
- The stub knows both the settings of FollowForkMode and DetachOnFork 
and follows those to reach the end result.
- The stub informs GDB of new processes if the child was followed.

Control flow B

- GDB connects to the stub and checks the availability of ForkFollowing.
- GDB sends the settings for FollowForkMode and DetachOnFork to the stub 
on connection startup or whenever these settings change.
- The stub runs the program (continue or step) and eventually notices it 
forked (fork or vfork).
- The stub sends the notification back to GDB stating it has detected a 
fork or vfork.
- GDB instructs the stub what to do with said process. Either follow the 
parent or child process.
- [TBD] The stub informs GDB the inferior has execd a new image and GDB 
tells the stub what to do.
- The stub informs GDB of new processes if the child was followed.

A delicate scenario that may require the second control flow is non-stop 
mode with displaced stepping. GDB needs to do some fixups for the 
newly-created process before letting it run freely.

Thoughts and comments are very welcome.

Luis