From: Michael Snyder <michsnyd@cisco.com>
To: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: [RFC] a prototype checkpoint-restart using core files
Date: Thu, 03 Nov 2005 01:55:00 -0000 [thread overview]
Message-ID: <43696953.9090601@cisco.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
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.
The idea was to experiment with the concept of doing
checkpoint and restore, by using a corefile as the
checkpoint file. Obviously it has limitations --
it doesn't save any kernel state, I/O state etc.
Just user state.
But it turns out that if you avoid those limitations,
it works! As a conservative rule of thumb, you can
go back to an earlier state so long as you don't cross
a system call. And in practice there are lots of
system calls that can be regarded as "stateless",
or that change only user state -- so you can cross
those.
I've only tried it on Linux, but it seems to me that
it should be pretty portable, at least to hosts for
which 'gcore' works.
This may be useful for anyone who wants to experiment
with the idea of checkpoint and restart, get a feel
for how it would work in practice, and look for
"gotchas" where the sudden state change might interfere
with something else in gdb. For a "real" checkpoint
and restart facility, we would probably want to handle
some amount of kernel state and I/O state, but
gcore/rcore might even be somewhat useful as-is
(at least to a knowledgeable user who understands
their limitations).
[-- Attachment #2: rcore.diff --]
[-- Type: text/plain, Size: 4948 bytes --]
Index: gcore.c
===================================================================
RCS file: /cvs/src/src/gdb/gcore.c,v
retrieving revision 1.17
diff -p -r1.17 gcore.c
*** gcore.c 15 Feb 2005 15:49:10 -0000 1.17
--- gcore.c 3 Nov 2005 01:19:53 -0000
*************** gcore_memory_sections (bfd *obfd)
*** 488,493 ****
--- 488,621 ----
return 1;
}
+ /* OK now, I want to add a new command to read a corefile,
+ and restore its state into the inferior process. Obviously
+ dangerous, probably want to make certain that they are
+ actually the same process! But we can put that off till
+ later. Let's see what's required. This should actually
+ be pretty easy. */
+
+ static void
+ load_core_sections (bfd *abfd, asection *asect, void *arg)
+ {
+ unsigned long from_tty = (unsigned long) arg;
+ char *memhunk;
+
+ if ((bfd_section_size (abfd, asect) > 0) &&
+ (bfd_get_section_flags (abfd, asect) & SEC_LOAD))
+ {
+ if (info_verbose && from_tty)
+ {
+ printf_filtered (_("Load core section %s"),
+ bfd_section_name (abfd, asect));
+ printf_filtered (_(", address 0x%08lx"),
+ (unsigned long) bfd_section_vma (abfd, asect));
+ printf_filtered (_(", size = %d"),
+ (int) bfd_section_size (abfd, asect));
+ printf_filtered (_(".\n"));
+ }
+ /* Fixme cleanup? */
+ memhunk = xmalloc (bfd_section_size (abfd, asect));
+ bfd_get_section_contents (abfd, asect, memhunk, 0,
+ bfd_section_size (abfd, asect));
+ target_write_memory (bfd_section_vma (abfd, asect),
+ memhunk,
+ bfd_section_size (abfd, asect));
+ xfree (memhunk);
+ }
+ }
+
+ #include <fcntl.h>
+ #ifndef O_BINARY
+ #define O_BINARY 0
+ #endif
+
+ #include "regcache.h"
+ #include "regset.h"
+
+ static void
+ rcore_command (char *args, int from_tty)
+ {
+ /* corelow.c core_open */
+ /* scratch_chan = open (filename)
+ temp_bfd = bfd_fdopenr (filename, gnutarget, scratch_chan)
+ bfd_check_format (temp_bfd, bfd_core)
+ build_section_table (core_bfd, to_sections, to_sections_end)
+ bfd_map_over_sections (core_bfd, myfunc)
+ myfunc will check for loadable, contents, and size,
+ and then write the section contents into memory at vma.
+ */
+ char *corefilename, corefilename_buffer[40], *scratch_path;
+ int scratch_chan;
+ bfd *core_bfd;
+
+ /* Can't restore a corefile without a target process. */
+ if (!target_has_execution)
+ noprocess ();
+
+ if (args && *args)
+ corefilename = args;
+ else
+ {
+ /* Default corefile name is "core.PID". */
+ sprintf (corefilename_buffer, "core.%d", PIDGET (inferior_ptid));
+ corefilename = corefilename_buffer;
+ }
+
+ if (info_verbose)
+ fprintf_filtered (gdb_stdout,
+ _("Opening corefile '%s' for input.\n"), corefilename);
+
+ scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, corefilename,
+ O_BINARY | O_RDONLY | O_LARGEFILE, 0, &scratch_path);
+ if (scratch_chan < 0)
+ perror_with_name (corefilename);
+
+ core_bfd = bfd_fdopenr (scratch_path, gnutarget, scratch_chan);
+ if (!core_bfd)
+ perror_with_name (scratch_path);
+
+ if (!bfd_check_format (core_bfd, bfd_core))
+ {
+ make_cleanup_bfd_close (core_bfd);
+ error (_("\"%s\" is not a core file: %s"),
+ corefilename, bfd_errmsg (bfd_get_error ()));
+ }
+
+ bfd_map_over_sections (core_bfd, load_core_sections, (void *) from_tty);
+ /* Now need to get/set registers. */
+ {
+ struct bfd_section *regsect = bfd_get_section_by_name (core_bfd, ".reg");
+ char *contents;
+ int size;
+
+ if (!regsect)
+ error (_("Couldn't find .reg section."));
+
+ size = bfd_section_size (core_bfd, regsect);
+ contents = xmalloc (size);
+ bfd_get_section_contents (core_bfd, regsect, contents, 0, size);
+
+ if (gdbarch_regset_from_core_section_p (current_gdbarch))
+ {
+ const struct regset *regset;
+
+ regset = gdbarch_regset_from_core_section (current_gdbarch,
+ ".reg", size);
+ if (!regset)
+ error (_("Failed to allocate regset."));
+
+ registers_changed ();
+ regset->supply_regset (regset, current_regcache,
+ -1, contents, size);
+ reinit_frame_cache ();
+ target_store_registers (-1);
+ }
+ }
+
+ bfd_close (core_bfd);
+ }
+
void
_initialize_gcore (void)
{
*************** Argument is optional filename. Default
*** 497,500 ****
--- 625,633 ----
add_com_alias ("gcore", "generate-core-file", class_files, 1);
exec_set_find_memory_regions (objfile_find_memory_regions);
+
+ add_com ("restore-core-file", class_files, rcore_command, _("\
+ Restore the machine state from a core file into the debugged process.\n\
+ Argument is optional filename. Default filename is 'core.<process_id>'."));
+ add_com_alias ("rcore", "restore-core-file", class_files, 1);
}
next reply other threads:[~2005-11-03 1:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-03 1:55 Michael Snyder [this message]
2005-11-07 4:01 ` Daniel Jacobowitz
2005-11-07 14:57 ` Eli Zaretskii
2005-11-07 19:43 ` Mark Kettenis
2005-11-07 19:50 ` Daniel Jacobowitz
2005-11-07 20:56 ` Michael Snyder
2005-11-07 20:43 ` Michael Snyder
2005-11-07 22:07 ` Eli Zaretskii
2005-11-08 6:05 ` Michael Snyder
2005-11-18 8:18 Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43696953.9090601@cisco.com \
--to=michsnyd@cisco.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox