Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hui Zhu <teawater@gmail.com>
To: Michael Snyder <msnyder@vmware.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [RFA/RFC] Add dump and load command to process record and replay
Date: Sat, 08 Aug 2009 13:28:00 -0000	[thread overview]
Message-ID: <daef60380908080137k4b5d9964n18c02d50e2a5a29b@mail.gmail.com> (raw)
In-Reply-To: <4A7C625B.8080005@vmware.com>

I think give him a query is very clear.

When he load, if there are some record log, it will query to user.  He
must choice remove the old record log or keep them.  He already know
what will happen.

Thanks,
Hui

On Sat, Aug 8, 2009 at 01:20, Michael Snyder<msnyder@vmware.com> wrote:
> Eli Zaretskii wrote:
>>>
>>> From: Hui Zhu <teawater@gmail.com>
>>> Date: Fri, 7 Aug 2009 11:34:20 +0800
>>> Cc: Eli Zaretskii <eliz@gnu.org>, "gdb-patches@sourceware.org"
>>> <gdb-patches@sourceware.org>
>>>
>>> I think a warning is clear to most of people.
>>>
>>> And when he get this warning.  He can delete the record list and load
>>> again.  He will lost nothing.
>>>
>>> If we delete the old record list, maybe he still need old record.  He
>>> will lost something.
>>
>> Instead of a warning, how about asking the user whether to discard the
>> old records or keep them?
>
> My concern is, in most cases keeping them will be the wrong thing to do.
> It will be very easy to create an internally inconsistent state, and
> rather unlikely to create one that is *not* internally inconsistant.
>
> Think about it -- we will be concatenating two independent sets of
> state changes, with no way of knowing that the actual machine state
> at the end of one is the same as the machine state at the beginning
> of the other.  When these are then replayed, their effect may have
> little or nothing to do with what the real machine would actually do.
>
> To actually get this right, you would have to be *sure* that your
> target machine is in the exact same state "now" (ie. when you do
> the load command) as it was at the *beginning* of the previous
> recording/debugging session.
>
> I would rather either make this a separate, "expert mode"
> command, or better still, leave it for a future patch to extend
> the basic (and safe) patch that we first accept.
>
>
>


  reply	other threads:[~2009-08-08  8:37 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01  7:31 Hui Zhu
2009-08-01  9:57 ` Eli Zaretskii
2009-08-01 19:20 ` Michael Snyder
2009-08-02  3:18   ` Michael Snyder
2009-08-02  5:58     ` Hui Zhu
2009-08-03  4:12       ` Hui Zhu
2009-08-03 18:29         ` Eli Zaretskii
2009-08-04  1:58           ` Hui Zhu
2009-08-04  2:07           ` Hui Zhu
2009-08-04 18:26             ` Eli Zaretskii
2009-08-04 20:01               ` Michael Snyder
2009-08-05  9:21                 ` Hui Zhu
2009-08-05 20:19                   ` [RFA/RFC] Add dump and load command to process record (file format etc) Michael Snyder
2009-08-06  2:17                     ` Hui Zhu
2009-08-12 14:11                       ` Michael Snyder
2009-08-12 15:16                         ` Tom Tromey
2009-08-12 22:38                           ` Michael Snyder
2009-08-16  0:04                             ` Hui Zhu
2009-08-05 21:23                   ` [RFA/RFC] Add dump and load command to process record and replay Michael Snyder
2009-08-06  3:14                     ` Eli Zaretskii
2009-08-06 14:16                       ` Hui Zhu
2009-08-07  3:27                         ` Michael Snyder
2009-08-07  3:29                           ` Hui Zhu
2009-08-07  3:34                             ` Michael Snyder
2009-08-07  4:06                               ` Hui Zhu
2009-08-07  8:41                                 ` Eli Zaretskii
2009-08-07  9:53                                   ` Hui Zhu
2009-08-07 12:51                                     ` Eli Zaretskii
2009-08-07 16:22                                       ` Hui Zhu
2009-08-07 17:42                                   ` Michael Snyder
2009-08-08 13:28                                     ` Hui Zhu [this message]
2009-08-10  3:09                                       ` Michael Snyder
2009-08-22 17:39                                         ` Hui Zhu
2009-08-23  1:14                                           ` Hui Zhu
2009-08-23 23:43                                           ` Michael Snyder
2009-08-24  8:20                                             ` Hui Zhu
2009-08-24 18:32                                               ` Michael Snyder
2009-08-25  8:47                                                 ` Hui Zhu
2009-08-26  1:40                                                   ` Michael Snyder
2009-08-26  2:59                                                     ` Michael Snyder
2009-08-29 15:53                                                       ` Hui Zhu
2009-08-29 18:06                                                         ` Eli Zaretskii
2009-08-29 18:28                                                           ` Hui Zhu
2009-08-29 20:26                                                             ` Eli Zaretskii
2009-08-29 20:39                                                               ` Michael Snyder
2009-08-30  3:03                                                                 ` Eli Zaretskii
2009-08-30  5:36                                                                   ` Hui Zhu
2009-08-30 23:40                                                                     ` Eli Zaretskii
2009-08-31  7:10                                                                       ` Hui Zhu
2009-09-05  3:30                                                                         ` Michael Snyder
2009-09-06 16:29                                                                           ` Hui Zhu
2009-08-29 20:05                                                           ` Michael Snyder
2009-08-29 20:33                                                             ` Eli Zaretskii
2009-08-29 21:20                                                               ` Michael Snyder
2022-01-21  6:46 Simon Sobisch via Gdb-patches
2022-01-24  9:26 ` Hui Zhu via Gdb-patches
2022-04-13 12:21   ` Simon Sobisch via Gdb-patches

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=daef60380908080137k4b5d9964n18c02d50e2a5a29b@mail.gmail.com \
    --to=teawater@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@vmware.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