This is the mail archive of the
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
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:
x = the_real_problem();
for (int i = x, i != 0, ++i)
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)