Re: [RFA/RFC] Add dump and load command to process record and replay

[Michael Snyder <msnyder@vmware.com>]

Hui Zhu wrote:
> 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.

This is my opinion.  The default should be to remove the old log
(not to query).  I think this will be both the most common case
and the safest.  We can maybe add a command option for those who
wish not to do that.

Anyone else have an opinion?

> 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.
>>
>>
>>
>