Re: embedded dataflow tracking code?

On Jul 24, 3:21 pm, Dennis Yurichev <dennis.yuric...@gmail.com> 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
> on.
>
> Probably, compiler backend could embed some dataflow tracking code
> between basic blocks and store information about all variables flow in
> some separate data segment..
>
> Are there any known attempts or projects or...?


At one point Borland debuggers offered the capability to step backward
from a breakpoint. (I don't know if this is still true.) I recall one
could graphically depict the backward control flow in the source. It
appeared this was done entirely in the debugger, as no recompilation
was ever necessary to use the feature. It seemed likely to me that the
debugger must have been trapping every instruction and maintaining a
trace of branch sources and overwritten data. The trace was consulted
in backward order to do the reverse stepping. It sounds like you are
proposing that the compiled program do the same thing. I guess there
could be some performance advantage in maintaining the trace without
context swaps.


I obtained more insight by finding the right Google term, which is
"reverse execution." Borland called it this in 1991-1992. Apparently
it's now a feature in GDB v7 and other modern debuggers, which seem to
have re-discovered it only lately.

Return to the comp.compilers page.
Search the comp.compilers archives again.