From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25545 invoked by alias); 20 Jul 2005 16:35:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25397 invoked by uid 22791); 20 Jul 2005 16:35:28 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 20 Jul 2005 16:35:28 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DvHXa-0000au-HT for gdb-patches@sourceware.org; Wed, 20 Jul 2005 12:35:26 -0400 Date: Wed, 20 Jul 2005 16:35:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [commit] Follow forks on HP-UX 11.xx Message-ID: <20050720163526.GA2164@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <200507201325.j6KDPZvi030460@elgar.sibelius.xs4all.nl> <20050720133457.GA29260@nevyn.them.org> <200507201629.j6KGTIxg019311@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507201629.j6KGTIxg019311@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00167.txt.bz2 On Wed, Jul 20, 2005 at 06:29:18PM +0200, Mark Kettenis wrote: > Hmm yes, spamming the output while following the output doesn't really > make sense. On the other hand, I think I'd like to see some > indication that GDB switched to following the child. But we should > make sure that all platforms that support this print the same message. > We should really move the printing of those messages into platform > independent code. Yes, we should, and the logic to control them. > And, the testcases for following vfork all rely on following exec. I > haven't enabled them, or that feature, because the current user > interface for following exec is so awful - it silently changes which > binary you're debugging, messes up configured breakpoints, etc etc. > > Hmm yes, I noticed that following execs is still disabled. And yes > the code is a mess. Any objection against removing it completely and > start afresh. I'd rather not touch it until we figure out a better interface; it's mildly useful as an example of where all the hooks would need to go. Unless it gets in the way, of course. > I don't recall if you have GNU/Linux systems to test on. If not, let > me know if you have testsuite changes you want to check with the > GNU/Linux implementation of fork following. > > Trashed the old SuSE on my amd64 box recently, so I'm going to attempt > installing Fedora Core 4 on it. You know whether that has a recent > enough kernel that has the fork/vfork following support in it? It should, unless RH's patches managed to break it; that's happened in the past, but I think it won't happen again in 2.6.x. Should be fine. > Anyway, to what extent does following vfork work on Linux? Does it > work flawlessly, or are there still some issues? I believe there's a nasty bit if you try to kill both processes while stopped at a vfork catchpoint, where you'll end up with a zombie. I haven't tried to reproduce that in at least a year, though, so it may be gone now. Otherwise it works quite just fine. -- Daniel Jacobowitz CodeSourcery, LLC