This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] a prototype checkpoint-restart using core files
- From: Michael Snyder <msnyder at redhat dot com>
- To: Stan Shebs <shebs at apple dot com>
- Cc: GDB Patches <gdb-patches at sources dot redhat dot com>, gdb at sources dot redhat dot com
- Date: Thu, 17 Nov 2005 19:36:55 -0800
- Subject: Re: [RFC] a prototype checkpoint-restart using core files
Stan Shebs wrote:
> Michael Snyder wrote:
>> Folks, this isn't for commit, just for discussion.
>>
>> Attached is an experimental patch that adds a command
>> "restore-core-file" or "rcore", which is the inverse of
>> "generate-core-file" (gcore). Instead of copying the
>> memory and register state of a process into a file,
>> it takes an existing corefile, and copies its memory
>> and register state into the child process.
>
> My prototype is even lamer :-) I use target read/write
> operations to collect state - but it can step backwards.
Don't beat up on yourself -- gcore works by using
target read and write. It's just a convenient
file format for saving target state.
> An improved version in the works uses vfork() to make
> core images more cheaply.
Aha! Linux fork is similar to vfork, in that it does
not immediately make a copy of user memory. Did you
have a chance to look at my later patch based on fork?
> One idea I've considered is getting the OS to set up
> some kind of notification at system calls, and then use
> it to warn the user who tries to resume the inferior
> after rolling back.
Yeah, ptrace on linux provides such a notification.
I know you don't have ptrace on your OS, but you might
think about mimicing the ptrace user interface, if only
so that you don't have to design one of your own. ;-)
Stan, do you remember the trace/replay utility that
Michael Chastain invented? I was thinking that would
come in pretty handy in this context.
Michael