|embedded dataflow tracking code? firstname.lastname@example.org (Dennis Yurichev) (2010-07-24)|
|Re: embedded dataflow tracking code? email@example.com (George Neuner) (2010-07-26)|
|Re: embedded dataflow tracking code? firstname.lastname@example.org (Gene) (2010-07-26)|
|Re: embedded dataflow tracking code? email@example.com (Tony Finch) (2010-07-27)|
|Re: embedded dataflow tracking code? firstname.lastname@example.org (Walter Banks) (2010-07-30)|
|From:||Tony Finch <email@example.com>|
|Date:||27 Jul 2010 14:07:25 +0100 (BST)|
|Posted-Date:||27 Jul 2010 10:36:53 EDT|
Dennis Yurichev <firstname.lastname@example.org> wrote:
>I would like to load debugger, attach to working process, and at some
>breakpoint, instead of numerical values in the CPU registers, I would
>like to see genesis of each value like "result of f(arg1, arg2,arg3)
>called at point X" or "result of comparison of values X and Y" and so
>Are there any known attempts or projects or...?
I recently read the following paper which is related to your question,
and which may be of interest as a starting point for digging through
Idempotent I/O for safe time travel
Zoltan Somogyi. Proceedings of the Fifth International Workshop on
Automated Debugging, Ghent, Belgium, September 2003.
Debuggers for logic programming languages have traditionally had a
capability most other debuggers did not: the ability to jump back to a
previous state of the program, effectively travelling back in time in
the history of the computation. This ``retry'' capability is very
useful, allowing programmers to examine in detail a part of the
computation that they previously stepped over. Unfortunately, it also
creates a problem: while the debugger may be able to restore the
previous values of variables, it cannot restore the part of the
program's state that is affected by I/O operations. If the part of the
computation being jumped back over performs I/O, then the program will
perform these I/O operations twice, which will result in unwanted
effects ranging from the benign (e.g. output appearing twice) to the
fatal (e.g. trying to close an already closed file).
We present a simple mechanism for ensuring that every I/O action
called for by the program is executed at most once, even if the
programmer asks the debugger to travel back in time from after the
action to before the action. The overhead of this mechanism is low
enough and can be controlled well enough to make it practical to use
it to debug computations that do significant amounts of I/O.
f.anthony.n.finch <email@example.com> http://dotat.at/
Return to the
Search the comp.compilers archives again.