Re: [RFA] Reverse Debugging, 1/5

[Michael Snyder <msnyder@vmware.com>]

Joel Brobecker wrote:
>>> 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.
> 
> I don't think that adding a parameter to resume will be beneficial
> at this point.  But I think it would be beneficial to have it in
> infrun instead of having the extra target method - the "target"
> in GDB's sense of the target layer doesn't have to remember the
> direction, since it can query infrun.  

All right, I know when I'm licked.  ;-)

Before I actually implement this, let me see if we're all
on the same page (Daniel, Joel, Pedro...)

If I put the "exec_direction" state variable in infrun,
then there's no point in having EITHER target vector
(target_set_execdir or target_get_execdir).  It'll just
be an ordinary gdb "set" command.

But then I ought to add a new target vector, something like
"to_can_go_backward"  (ok, to_can_reverse), because I've
presently overloaded this functionality onto the
target_get/set_execdir methods.

Then, on "set exec-dir reverse", infrun will call
target_can_reverse, and reject accordingly.

The target_ops, such as remote.c, instead of
checking its own local state variable, will call
infrun_get_exec_direction every time target_resume
is called.

Right?