This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] a prototype checkpoint-restart using core files
Mark Kettenis wrote:
Date: Mon, 07 Nov 2005 06:40:22 +0200
From: Eli Zaretskii <eliz@gnu.org>
Date: Sun, 6 Nov 2005 19:19:37 -0500
From: Daniel Jacobowitz <drow@false.org>
Cc: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
I've got to say that this is amazingly cool.
Afraid that's all the comments I have time for at the moment :-)
I agree, and I'd add that getting this into GDB soon would be good.
Heh, I'd expected Eli to ask for documentation ;-)
Anyway, in this cause I think that's important since I expect a lot of
users won't understand its limitations.
If I read the code correctly, there is one rather serious limitation
though: restoring mmapped area's will fail if the same area isn't
mapped in the target process. Especially on systems that randomize
the location of mmapped memory this will make the usefullness of this
feature pretty limited :(.
Yes, I'm still puzzling over that one. However, it would
mostly only happen (sic) if you are going forward in time,
not backward. In particular, if you create a new process,
then try to feed it a corefile from an old process that
was further along in its execution.
If you save a gcore file, run forward, and then reload
the previously saved gcore file back into the *same* process
(ie. go backward in time), the mmaped areas will almost
always be present -- unles someone explicitly unmaps them.
As for your broader point, I agree, I don't think this is
ready for exposure to average users. I would like to see
it get some play from "sophisticated" users such as you
guys, who may understand the limitations and help to
characterize them.