Using reverse execution

Stan Shebs shebs@apple.com
Fri Sep 23 23:20:00 GMT 2005


(Been in Cupertino talking about reverse execution to Apple people,
just now getting caught up)

Eli Zaretskii wrote:

>>Date: Fri, 16 Sep 2005 11:02:50 -0700
>>From: Stan Shebs <shebs@apple.com>
>>Cc: gdb@sources.redhat.com
>>
>>Eli Zaretskii wrote:
>>
>>
>>>What features can be implemented without hacking the kernel?
>>>
>>>
>>If you limited reversing to designated regions, and single-stepped
>>every instruction in the range, collected the exact data changes
>>(by disassembling the instructions) and only allowed examination
>>rather than re-executing from any given point, all that just needs
>>existing GDB machinery. Is it useful?
>>
>
>Sorry, you lost me.  Can you describe this in smaller words?
>
ODB works by hacking up the bytecode interpreter to log what every
bytecode does, recording addresses and data values. After the
program runs, you have a gigantic log, and you look at it with a
debugger-type interface. Since the log contains every before-and-after
change to objects etc, it's just a matter of rooting through it to
be able to display any value at any time. But the program execution
is already over, so there's no way to set a variable and continue,
call a method, or do anything else to alter execution.

An analogy I used this week is that of a "time-traveler's telescope" -
you can focus in on any point in the past, and study it closely from
the present day, but you can't alter it. A handy way to sidestep
paradox, but it also precludes "what-if" experiments; you'd have to
restart the program before you could make the program go a different way.

>>At least somebody thinks so, because I just described how the
>>omniscient debugger works (using Java bytecodes instead of machine
>>instructions).
>>
>
>As I understood the description of the omniscient debugger, it would
>be very useful.
>
Indeed it seems so. That would be a very nice outcome - we could get
a powerful new feature without having to make a scarily-large
commitment to a feature that doesn't current have a large body of
users demanding it already.

Stan



More information about the Gdb mailing list