This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using reverse execution


(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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]