This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Reverse Debugging, 1/5
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.