This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] Support for reverse-execution
- From: Paul Schlie <schlie at comcast dot net>
- To: Russell Shaw <rjshaw at netspace dot net dot au>,<gdb at sources dot redhat dot com>
- Date: Sat, 21 May 2005 11:53:43 -0400
- Subject: Re: [discuss] Support for reverse-execution
> Russell Shaw <rjshaw at netspace dot net dot au> writes:
> Yes, that's what i meant (every step). It could be configureable so
> that the policy can be set to every user-stop, every function call,
> or disabled alltogether. The idea is that you could run from main()
> until a segfault happens, then "back 10" and step thru the last few
> actions.
There's nothing inherently wrong with the strategy, as long as one
understands that the utility it provides can be deceptive; for example
given the following simple program fragment:
void foo(void)
{
x = the_real_problem();
for (int i = x, i != 0, ++i)
{
something();
}
}
foo(); // step from here.
... ; // to here.
It's clear that tracing and recording the last N states can easily
be consumed in uninteresting code.
A similar strategy may constrain the N full state traces/snapshots
to only entries into basic blocks, which both allows N to be smaller,
while simultaneously enabling a broader swipe of interesting locations
to recorded for subsequent inspection. This ideally either requires that
the compiled program be analyzed to apriority identify these entry points,
although a close approximation may be determined at runtime by only
recording state traces at points of control flow change; i.e. capture and
record state only upon a given condition, (typically when the PC != PC + 1,
for example), or may be generalized to any arbitrary set of "watch-point"
conditions; as an incremental nicety, not unlike the HW trace history buffer
support that some processors provide. (and could be enabled by GDB directly,
with or without target support)