Re: Follow-fork-mode and inferiors

[Kevin Pouget <kevin.pouget@gmail.com>]

oh, I didn't now this  `follow-exec-mode' setting, which explains why
we might want to create a new inferior

but (as the name suggests) it's not involved when the inferior forks,
and GDB behaves as if it were set to 'new'. Unfortunately,
`follow-fork-mode' is already used to follow the child or the parent
...



Kevin
--

(gdb) help set follow-exec-mode
Set debugger response to a program call of exec.
An exec call replaces the program image of a process.

follow-exec-mode can be:

  new - the debugger creates a new inferior and rebinds the process
to this new inferior.  The program the process was running before
the exec call can be restarted afterwards by restarting the original
inferior.

  same - the debugger keeps the process bound to the same inferior.
The new executable image replaces the previous executable loaded in
the inferior.  Restarting the inferior after the exec call restarts
the executable the process was running after the exec call.

By default, the debugger will use the same inferior.

(gdb) help set follow-fork-mode
Set debugger response to a program call of fork or vfork.
A fork or vfork creates a new process.  follow-fork-mode can be:
  parent  - the original process is debugged after a fork
  child   - the new process is debugged after a fork
The unfollowed process will continue to run.
By default, the debugger will follow the parent process.

On Wed, Apr 13, 2011 at 10:29 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Kevin> why are there two inferiors? I expected either to stay in inf 1
> Kevin> (if the pid of an inferior can change) or inf 1 to disappear, but
> Kevin> not to keep both of them!
>
> I suspect that it may be due to your `follow-exec-mode' setting.
> I am not really certain though.
>
> Tom
>