This is the mail archive of the gdb@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]

Feature Parity: Remote fork following


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


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