Re: [RFA] Resubmit process record and replay, 6/10

[Pedro Alves <pedro@codesourcery.com>]

On Monday 24 November 2008 03:23:06, teawater wrote:
> > Not sure if it's "are we recording" or are we "replaying", or
> > a mix of both.  In any case, could each call site on the common
> > code be replaced by a new suitable target method/property?
> 
> Could you give me more message on it? I am not very clear your mean.

What is the property or state that you want to check
here?  You should export that through the target_ops interface,
instead of making infrun.c tied to a record.c and
the record target.

Currently, GDB only distinguises reverse and forward
execution.  Does it also need to know that replaying is a
special case of forward execution?

Perhaps you want to check if the current
target is replaying?

 target_is_replaying()

?

Note that this would be a proper target_ops method, not
a reference record_ops, like in your current macro.

But, why do you need to protect `proceed' with the record
target, while reverse/replay debugging against sid or WMware
or Virtutech didn't need it?  If they also need it, or will
need it, what's the check that GDB should do to prevent
the bad writes from happening in those targets too?

And, why only in `proceed'?

Figuring this out, and knowing *exactly* what is it that this
check is protecting against will let us know if there's some
other better way.  Plain ignoring writes may or may not be
the right thing to do here.  Can you show an example of what
you're protecting against?

E.g., should you instead prohibit the 'jump ADDR' command at a
higher layer when replaying or executing backwards?

-- 
Pedro Alves