[lizard] A few ideas

[Aditya T. <woo...@ya...>]

Actually, I can imagine how an inerpreter-like tool could be used to implement reversibility...actually, it would be more of a "reverse interpreter" , very very similar to the reverse instruction generator Ravi spoke about. So instead of generating (like a compiler) the reverse instructions, you would just do it at runtime (like an interpreter). what say?
 
Another thing I wanted to bring up is that the reversible/replay debugging is a pretty old idea now ( there was even that PLDI2000 paper which spoke about it). Here is one useful extension to the replay debugging paradigm:
The drawback of replay deugging is that it is too costly, and frankly all it does (if you exclude reverse watchpoints) is let you navigate thru this (potentially huge execution).
Here is a (rather simple, but realistic) problem i want to solve: determine whether my program uses the file api correctly viz. to read a file, i have to open it first; i cannot close an unopened file; to write a file i have to open it in write mode. I can to do some part of this statically, but the analysis will give me an over approximation. Hence i do it at runtime. If the "replay debugger" can check this and take me the execution point where the api was used in a wrong way, i'd be very happy!
 
A little bit more about the general problem now. You have a finite state machine given to you which is used as the specification of the API.  Then you need to have a way of updating the autmata state i.e. when i execute  ' fp=fopen() ' the state machine associated with "fp" goes from UNINIT state to OPENED state. 
 
You can have a few default state machines, but in theory you should let the used specify it in some, preferably graphical, way.
 
Given these state machines, you can either checkpoint the whole state during execution and later during the debugging session, do the appropriate state machine updates and all that jazz.
This way the user can change the state machines during the debugging session.
OR
Only save enough state (using dynamic slicing) to provide information regarding the relevant variables affecting the state machines you are tracking.
 
I hope you got the general idea: let the viewer provide some abstract property he wants you to track. I can probably explain better on a blackboard :-P
 
Anyway, I think this idea has enough mea t to keep 4 ppl busy; some visualization could enter regarding the state machines.
 
Some interesting stuff could come up regarding reversing the state machines and tracking them during the reverse execution.
 
I see this idea as a generalisation of the reverse watchpoints idea, and some (basic) parts of this could be implemented using a small script which gives the appropriate reverse watchpoint queries.
 
Aditya


Ravi Ramaseshan <ram...@gm...> wrote:
Hi,

-- Kalpak Shah wrote:

> Visual Basic has reversible debugging capability with the help of an
> interpreter which it uses at debugging stage. I found a few
> interpreters for C viz. Ch(www.softintegration.com) and EiC. EiC can
> be embedded or linked to other programs. We could use it along with
> GDB to provide this functionality.

I have no idea as to how an interpreter would help you implement a
reversible debugger.

> What were the major roadblocks that you encountered when you thought
> about this idea? I thought that the recompilation of the changed
> code would be the biggest problem, but i guess it could be solved
> with the help of an interpreter.

Correct me if I am wrong, but I think when you say "recompilation of
the changed code" you mean generating a set of reverse instructions
for a code fragment, right ? Well, we implemented a 'replay' debugger
and hence would never face such a problem. We never generated a
reverse set of instructions. If this is not what you're talking about
then your enigmatic mail just got murkier ;-)

We did not use any check pointing tool but implemented one of our own.
The only recompilation that we ever did (which I'm not sure is up on
the CVS yet) is when we instrumented the program at compile time to
insert the tracing code.

-- 
Ravi Ramaseshan

" Reality is only something we believe in strongly. "


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Lizard-hackers mailing list
Liz...@li...
https://lists.sourceforge.net/lists/listinfo/lizard-hackers

		
---------------------------------
 Start your day with Yahoo! - make it your home page