This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Linux Checkpoints, take 3


> Date: Tue, 03 Jan 2006 15:53:41 -0800
> From: Michael Snyder <msnyder@redhat.com>
> 
> 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  <msnyder@redhat.com>
> >>
> >>2005-12-19  Michael Van Meter Snyder  <michsnyd@clwang-lnx.cisco.com>
> 
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]