Omniscient Debugging - Next Generation Debugging
Our aim is to produce a debugger that can control not only the flow of execution but one that can control the direction of execution. That is, Debuggger that not only step forwards but one that can also step backwards .
Motivation:
The first debugger DDT(http://www.elook.org/computing/ddt.htm) came out in 1961. One look at the commands(http://web.mit.edu/afs/net/project/cgw/src/ddt.68/ddt.cmds) will reveal that it has the same features of the contemperory debuggers of today. How is that bad? Because not many people(Good programmers to the very least) don't use debuggers. Notably, an informal survey (a show of hands in conferences, classes, etc.) of several thousand programmers reveals that roughly 90% of all programmers debug their programs strictly by use of println()!
A 'Reverse' Debugger
The most "obvious" way to debug a system is to put it into action and run it through its paces. When you notice something not working as intended, you should be able to stop the process and go backwards to figure out what went wrong. This should be as wasy as say, hitting the <DelBack> key to correct errors while typing out text in text editors.
Omniscient Debugging
An omniscient debugger works by collecting information about every state change (every variable assignment of any type) and every method call in a program. After the program is finished, it brings up a debugger display and allows the programmer to look at the state of the program at any time desired. The programmer can select any variable and go "backwards in time" to see where it was set, what all of its values were. It will be possible to "single step" the program forwards or backwards, to step to any method call, follow any exception throw, any context switch.