Re: [RFA] Reverse Debugging, 1/5

[Michael Snyder <msnyder@vmware.com>]

Daniel Jacobowitz wrote:
> On Mon, Oct 06, 2008 at 02:17:25PM -0700, Michael Snyder wrote:
>> You're going to send "to_set_direction" to the target,
>> and then you're going to assume that you know what the
>> state is later on, rather than asking the target?  What
>> if the target gets it wrong?  Now you're out of sync.
> 
> Huh?  No, part of every resume.

It's not part of resume.  That was the very first design
decision.  We didn't modify resume, because it would require
modifying every existing target.  Instead, we added a set
execution direction method, which has to be called before
resume (and after, depending).

So right now there are two ways this gets invoked:

1) By a one-shot reverse command, reverse-xxx (where
xxx is step/stepi/next/nexti/continue/finish/until).
In that case, we do:
     target_set_exec_dir (reverse);
     step/next/finish/continue/???
     target_set_exec_dir (forward);
2) By the user command set exec-direction, in which case
we leave it in the user-supplied state until the user
changes it again.

All resumes get the implied direction that was specified
in the last target_set_exec_dir.  Resume doesn't have
an extra parameter, but if you do reverse-step, for
instance, there may be many resumes between the two
calls to target_set_exec_dir.



>> If we do keep the direction-state in the core, where would
>> we put it?  In the ecs?  In a global variable in infrun?
> 
> In infrun, the same as any other user supplied execution state.
> For instance the scheduler-locking setting.

I'm ok with that, if that's what we decide.

But understand -- the target HAS to remember this state,
so now we are duplicating state.  Unles we go back and
reverse that very first design decision and add a parameter
to resume -- which will be a lot of work.