Re: [RFA] Reverse Debugging, 1/5

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 06 October 2008 22:00:37, Michael Snyder wrote:

Certainly you've been through this much more than all of us,
so, I'm just going to give a knee-jerk like reaction to this.
It's not really a profoundly thought about opinion, so wear
sunglasses...

> Making no assumptions about HOW the target sets the direction,
> it seems likely that at least *some* targets will have to
> remember this state locally.  Whereas there is no reason
> for core-gdb to have to remember the state locally, if it can
> always get it from the target.

If we consider the packets you're introducing to the remote protocol,
it looks a bit that these abstractions colide.  That is,
if you have a way to set the direction on the target, then you
wouldn't need a special step-backwards packet.  You'd just
pass down the direction and issue a normal step...

A per-target property may seems to make sense on
single-threaded,single-inferior targets, but when you add support
for multi-inferiors per target (e.g., extended-remote has some of it now,
and I'm going to push more of it), or multi-threaded support, the
per-target setting may not make sense anymore --- explicit requests
at the target resume interface (just like your new packets) may make
more sense.  Imagine forward execution non-stop debugging in all threads
but one, which the user is examining in reverse.  What's the target
direction in this case?

> It seems a worse duplication to keep the same state information
> simultaneously in the target and in the core, since now you
> have to worry about them getting out of sync.
> 
> At worst, a target will need to maintain an int's worth of state
> locally, and so long as we're never running two targets at the
> same time, there's no synchronization issue.
> 

The question to me is --- when/why does the target (as in, the debug
API abstraction) ever need to know about the current direction that
it couldn't get from the core's request?

-- 
Pedro Alves