This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Reverse Debugging, 1/5
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Michael Snyder <msnyder at vmware dot com>, Joel Brobecker <brobecker at adacore dot com>, Daniel Jacobowitz <drow at false dot org>, teawater <teawater at gmail dot com>
- Date: Mon, 6 Oct 2008 22:45:31 +0100
- Subject: Re: [RFA] Reverse Debugging, 1/5
- References: <48E3CCB6.email@example.com> <20081006203021.GA21853@adacore.com> <48EA7C75.firstname.lastname@example.org>
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
> 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?