Re: [RFA] Reverse Debugging, 1/5

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> 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...

"With Reverse Debugging, the future's so bright,
ya gotta wear shades!"    ;-)

>> 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...

Sorry, verbal ambiguity on my part.

Where I've been saying "target" in this thread, I
have been meaning "the target_ops implementation",
eg. (but not limited to) remote.c

I believe you're thinking "target" as in for instance
"gdbserver" or VirtuTech/Simics simulator.

Two different API's.

The API for the target_ops target is
   target_set_exec_dir
   target_resume
   target_wait

This has an explicit persistant state -- the exec_dir.

The API for remote targets is 'c', 'bc', 's', 'bs'.
In this, there is no persistant state.

But it's important to remember that GDB proper does not
know anything about the remote protocol API.  Only
one or more target_ops implementations know about that,
and there is no particular reason for the two APIs to
resemble each other.  The API for (eg.) a native target
is likely to be completely different.


> 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?

Yakkk!!!

OK, I don't have a story for multi-thread reverse yet,
at all, and I certainly don't have one for multi-thread
in which some threads are running forward and others
are running in reverse!

Nor do I have a story for multi-process or multi-target.

Planning ahead is great, but at some point, you have to
say "that's for a later patch".


>> 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?

At this interface layer, the core's requests look like:

   target_set_exec_dir
   target_resume
   target_wait
   [repeat]
   target_set_exec_dir

So there may be many resume/wait calls between calls to set_exec_dir.
This means that the target_ops module MUST remember the state, whether
or not the core remembers it also.