From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31653 invoked by alias); 4 Jan 2006 19:16:36 -0000 Received: (qmail 31642 invoked by uid 22791); 4 Jan 2006 19:16:35 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 04 Jan 2006 19:16:33 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k04JEW0B004373; Wed, 4 Jan 2006 20:14:32 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k04JEV5E008643; Wed, 4 Jan 2006 20:14:31 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k04JEVdO003889; Wed, 4 Jan 2006 20:14:31 +0100 (CET) Date: Wed, 04 Jan 2006 19:16:00 -0000 Message-Id: <200601041914.k04JEVdO003889@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: msnyder@redhat.com CC: mark.kettenis@xs4all.nl, gdb-patches@sources.redhat.com, drow@false.org In-reply-to: <43BB0E85.5050003@redhat.com> (message from Michael Snyder on Tue, 03 Jan 2006 15:53:41 -0800) Subject: Re: [RFA] Linux Checkpoints, take 3 References: <43AC7D2E.6020609@redhat.com> <200512261533.jBQFXCwt001363@elgar.sibelius.xs4all.nl> <43BB0E85.5050003@redhat.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00047.txt.bz2 > Date: Tue, 03 Jan 2006 15:53:41 -0800 > From: Michael Snyder > > Mark Kettenis wrote: > > > > > > >>+ /* Now save the 'state' (file position) of all open file descriptors. > >>+ Unfortunately fork does not take care of that for us... */ > > > > > > Hmm, fork(2) clones it file descroptors but both file descriptors > > refer to the same open file description. Nasty. Wonder whether it'd > > be possible to copy the open file descriptorions too. Well, I guess > > the point was to do this without kernel support... > > This time around, anyway. I like the successive approximation approach. > So much the better if, on the next pass, we can do even better by using > kernel support. > > > Anyway, a few problems that I spotted: > > > > 1. Please drop the "extern" from _initialize_linux_fork() (and the > > associated comment). You'll need an explicit prototype again, like: > > > > /* Prevent warning from -Wmissing-prototypes. */ > > void _initialize_linux_fork (void); > > I don't understand the motivation, but OK. It's a while ago since we last discussed this, but we don't want "extern" variable declarations in .c files; those should go into the appropriate .h file. To make it easier to check whether we make any mistakes (the ARI checks for this), it's easier to completely ban "extern" from .c files > > 5. Could you seperate out the "Detaching after fork from child > > process" printing? > > Sorry, don't understand the request. Bleah, I misread your diff; please ignore this. > > > And from the nitpicking department: > > > > 1. The comments on the #includes are a bit silly. I'd rather not see > > any unless there's something really unobvious going on. They get > > out of data pretty soon anyway. > > Ooooook, sure... > > > 2. Please don't put the function name in comments above the function. > > (call_lseek, linux_fork_killall, linux_fork_mourn_inferior, > > 'k... > > > 3. Really sorry to hear that you're suffering from a split personality > > problem: > > > > > >>2005-12-19 Michael Snyder > >> > >>2005-12-19 Michael Van Meter Snyder > > Well, that's life on the Information Superhighway... > > > Otherwise, I think it's ok. It's a bit sad that this is a Linux-only > > implementation, but then it's mostly Linux-specific code. > > Well, it's intimately tied in with the linux follow-fork code. > It should be possible to do something similar with other systems > where follow-fork works -- but the only other one I'm aware of is > hpux. Heh, OpenBSD 3.9 will have follow-fork ;-). Anyway, please go ahead and commit this. Mark