Re: [discuss] Support for reverse-execution

Re: [discuss] Support for reverse-execution

[Paul Schlie]

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

Re: [discuss] Support for reverse-execution (related efficiency issues)

[Paul Schlie]

While although not seemingly related, issues raised like:

 http://sources.redhat.com/ml/gdb/2005-05/msg00178.html

likely also need to be considered, they can materially effect
the relative efficiency of any basis of such a capability.