Follow-fork-mode / detach-on-fork expected behavior?

["Breazeal, Don" <donb@codesourcery.com>]

Hi

I'm working on implementation of follow-fork in gdbserver.  My intent is to make it work just like it works in native GDB.  However, I am confused by what looks like inconsistent behavior in native GDB.  I'm hoping to get some feedback on my observations so that I know how to proceed.  I want to make sure things are working in native GDB before going any further with gdbserver.

Apologies for the length of this email.  The only way I can think of to explain my questions is by describing what I see in a test case.  I'm using a test case that uses 'fork' (not 'vfork') in all-stop mode (gdb.base/foll-fork).  Aside from the fork mode settings, the commands are:
(gdb) set verbose   # to see the fork msgs
(gdb) break main
(gdb) run
(gdb) next 2        # this executes past the fork call

The behavior is inconsistent when following the child, depending on the setting for detach-on-fork.  Below is the behavior I see in the four possible combinations of fork settings after the 'next 2' command is entered, along with my specific questions:

1) follow parent / detach child (default settings)
  -  prints msg about detaching after fork
  -  stops after the next command in the parent
  -  one inferior left

2) follow parent / don't detach child
  -  prints [New process] msg
  -  prints symbol reading/loading msgs
  -  stops in parent after next
  -  two inferiors left, info inferiors shows pids of both

So far, so good, this is what I expect.

3) follow child / detach parent
  -  prints msg about attach to child after fork
  -  prints [New process] msg
  -  prints [Switching to process ] msg
  -  stops in child after 'next' command
  -  two inferiors left, info inferiors shows parent 'null'

This looks like there might be a problem:
  Q1: shouldn't there only be one inferior?
  Q2: should the child have stopped?
The manual doesn't make this completely clear.

4) follow child / don't detach parent
  -  prints msg about attach to child after fork
  -  prints [New process] msg
  -  prints symbol reading/loading msgs
  -  child runs to completion
  -  two inferiors left, info inferiors shows child 'null'

Something seems wrong here.  
  Q3: to be consistent, shouldn't the child process either have stopped after the 'next' command in both (3) and (4) or run to completion in both cases?

I'd appreciate it if someone could clarify the expected behavior for me, or if what I'm seeing is expected, explain the rationale.  If something needs to be fixed in the native implementation, I'll want to look at that before continuing with the remote case.
Thanks
--Don