Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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);
  }

             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