Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Schlie <schlie@comcast.net>
To: <gdb@sources.redhat.com>
Subject: Re: [discuss] going back: reverse-execution vs. checkpoint/restart
Date: Tue, 24 May 2005 04:47:00 -0000	[thread overview]
Message-ID: <BEB82A00.A40F%schlie@comcast.net> (raw)

In hopes it may be helpful, upon reviewing some of the earlier posts:

- checkpoints/undo-reverse can never "fail" even if the current
  program state is manually modifed, as by definition a check-pointed
  state represents the "state" of the program at some previous point in
  time, therefore insensitive to it's current state (altered or not,
  with a caveat noted below).

- it's likely a good idea to differentiate check-pointing a process
  or even a thread running on an OS, from check-pointing the entire
  machine inclusive of the OS and all of it's processes. (as where the
  later may be infeasible in the general case except for very small
  embedded systems, the former may be typically reasonable with the
  understanding that the state of the world around it on the other
  side of the system interfaces represented in other process states
  would not have been check-pointed, therefore are in what ever state
  they were last in; which is likely of little consequence if one is
  attempting to debug an algorithm which doesn't make sensitive system
  calls, however if a socket was opened in a network protocol loop but
  not closed prior to reverting to a previous program state which may
  have been prior to the socket being originally opened, things could
  get weird, so there's no magic, powerful features may require
  delicate piloting.)

- in all reasonably useful cases, GDB has direct access to all the
  information required without necessity of explicit target support,
  who's implementation my be partitioned in such a way that targets
  may then improve the efficiency of the solution in an incremental
  manor depending on the sophistication of the target, without
  requiring that any target support any particular feature to enable
  basic check-point/restart, and undo-reverse execution; although
  it will be true that in order to achieve a level of efficiency
  likely required to interactively do so for large complex processes,
  some amount of target assist may be practically necessary (however
  there's no magic, check-pointing an entire multi-process platform
  may never be practical under any circumstance, regardless of target
  support or not).



             reply	other threads:[~2005-05-24  4:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-24  4:47 Paul Schlie [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-05-23 18:51 Michael Snyder
2005-05-23 19:01 ` Daniel Jacobowitz
2005-05-23 19:15   ` Michael Snyder
2005-05-23 19:32 ` Dan Shearer
2005-05-23 19:37   ` Dan Shearer

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=BEB82A00.A40F%schlie@comcast.net \
    --to=schlie@comcast.net \
    --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