This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Linux Checkpoints, take 3
- From: Michael Snyder <msnyder at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sources dot redhat dot com, drow at false dot org
- Date: 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>
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.
2. Please update the copyright notice to use (C) and the new FSF
address.
Good catch, thanks.
3. Replace the FORKS_EXISTS() macro with a forks_exists_p() function?
Or inline it if you don't think it's ever going to be changed.
'k.
4. Aren't the values used for SEEK_SET/SEEK_CUR the same on all Linux
ports? In that case perhaps #defining LINUX_SEEK_SET 0, and using
LINUX_SEEK_SET would be a good solution.
5. Could you seperate out the "Detaching after fork from child
process" printing?
Sorry, don't understand the request.
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.
I'll see if
I can rig up something for OpenBSD, and then we can sort out what bits
are target-independent.
If you can intercept the fork system call, it should be doable.