This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [reverse RFC] Add documentation for process record and replay


Replay mode is designed to replay the inferior execute behaver (Now,
it just care about registers and memory change. It will add more in
the future) in before.

So it don't replay what you were talk about.

On Sat, Oct 18, 2008 at 03:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: "Jakob Engblom" <jakob@virtutech.com>
>> Cc: <msnyder@vmware.com>,
>>       <gdb-patches@sourceware.org>
>> Date: Fri, 17 Oct 2008 21:31:36 +0200
>>
>> > > > signals? crashes? etc.  Are there things that simply cannot be
>> > > > reproduced exactly, due to fundamental limitations of the replay
>> > > > target?
>> >
>> > Do you have an opinion about these concerns?
>>
>> I would like to jump in here and point out that this will depend on the nature
>> of the target.  Simics, and presumably other full-system simulation solutions,
>> can replay the entire IO of a machine.  This includes any external IO that is
>> asynch to the simulator execution (such as network packets and user input).
>> Between machines in a simulated network of machines, replay is obviously
>> perfect.
>>
>> If you try to do this on a live machine, it is a bit more tricky.
>>
>> So this is best left to the underlying mechanism, in my experience.
>
> We should at least describe a couple of possibilities and tell the
> reader to consult the documentation of the particular target for the
> full details.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]