From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-39281-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 15751 invoked by alias); 1 Jun 2011 15:29:38 -0000
Received: (qmail 15741 invoked by uid 22791); 1 Jun 2011 15:29:37 -0000
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Jun 2011 15:29:22 +0000
Received: (qmail 21073 invoked from network); 1 Jun 2011 15:29:21 -0000
Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2)  by mail.codesourcery.com with ESMTPA; 1 Jun 2011 15:29:21 -0000
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: Follow-fork-mode and inferiors
Date: Wed, 01 Jun 2011 15:29:00 -0000
User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; )
Cc: Kevin Pouget <kevin.pouget@gmail.com>
References: <BANLkTikpEhjP-RPyLFcwoF=nC3K+oas-ZQ@mail.gmail.com> <BANLkTin1PTQ5vuO5h+eoAzkRgym0HCfCmw@mail.gmail.com>
In-Reply-To: <BANLkTin1PTQ5vuO5h+eoAzkRgym0HCfCmw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201106011629.18877.pedro@codesourcery.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2011-06/txt/msg00000.txt.bz2

On Wednesday 13 April 2011 14:33:01, Kevin Pouget wrote:
> Hello,
> 
> I noticed a behavior which appears strange to me, I would like to know
> if it was expected:
> 
> > (gdb) list
> > 1    int main() {
> > 2        fork() ;
> > 3    }
> >
> > (gdb) break 3
> > (gdb) set follow-fork-mode child
> > (gdb) run
> > ...
> > Breakpoint 1, main () at fork.c:3
> > 3    }
> > (gdb) info inferiors
> >   Num  Description       Executable
> > * 2    process 26039     /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
> >   1    <null>            /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
> 
> why are there two inferiors? I expected either to stay in inf 1 (if
> the pid of an inferior can change) or inf 1 to disappear, but not to
> keep both of them!

Hmm, if detach-on-fork is on (the default), yeah.
I'd argue for staying in inf 1.  linux-nat.c:linux_child_follow_fork
is the place to look.  The problem is the vfork case, and
what to do with the vfork parent.

-- 
Pedro Alves