[lizard] Re: A few ideas

[Kalpak S. <kal...@gm...>]

hi aditya,=20

I tried to follow up on the leads you gave us.=20

On 8/30/05, Aditya Thakur <woo...@ya...> wrote:
>=20
> Actually, I can imagine how an inerpreter-like tool could be used to=20
> implement reversibility...actually, it would be more of a "reverse=20
> interpreter" , very very similar to the reverse instruction generator Rav=
i=20
> spoke about. So instead of generating (like a compiler) the reverse=20
> instructions, you would just do it at runtime (like an interpreter). what=
=20
> say?
>=20

I didnt find any great C interpreters(other than EiC) which could be used t=
o=20
perform the "reverse interpreter" operation. Also we couldnt come up with=
=20
any convincing solution for the problem Ravi mentioned. Would this be more=
=20
beneficial in presence of available reversible debuggers?

Another thing I wanted to bring up is that the reversible/replay debugging=
=20
> is a pretty old idea now ( there was even that PLDI2000 paper which spoke=
=20
> 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=
=20
> it does (if you exclude reverse watchpoints) is let you navigate thru thi=
s=20
> (potentially huge execution).
> Here is a (rather simple, but realistic) problem i want to solve:=20
> determine whether my program uses the file api correctly viz. to read a=
=20
> file, i have to open it first; i cannot close an unopened file; to write =
a=20
> file i have to open it in write mode. I can to do some part of this=20
> statically, but the analysis will give me an over approximation. Hence i =
do=20
> it at runtime. If the "replay debugger" can check this and take me the=20
> execution point where the api was used in a wrong way, i'd be very happy!
>=20

This sound good for certain API, but we are not exactly sure how it would=
=20
help in more generalised cases. For example, if we are tracking a variable,=
=20
this can be done with conditional breakpoints. Something like Valgrind=20
checks for memory leaks by tracing the memory related API. Then would we be=
=20
doing such a great job?

A little bit more about the general problem now. You have a finite state=20
> machine given to you which is used as the specification of the API. Then =
you=20
> need to have a way of updating the autmata state i.e. when i execute '=20
> fp=3Dfopen() ' the state machine associated with "fp" goes from UNINIT st=
ate=20
> to OPENED state.=20
>  You can have a few default state machines, but in theory you should let=
=20
> the used specify it in some, preferably graphical, way.
>  Given these state machines, you can either checkpoint the whole state=20
> during execution and later during the debugging session, do the appropria=
te=20
> state machine updates and all that jazz.
> This way the user can change the state machines during the debugging=20
> session.
> OR
> Only save enough state (using dynamic slicing) to provide information=20
> regarding the relevant variables affecting the state machines you are=20
> tracking.
>=20

The checkpointing stuff could be done by instrumenting the code, and the=20
graphical depiction of state machines could also be provided. But in case o=
f=20
tracking APIs, as it is if there is an error in the API, the program will=
=20
give a runtime error like in the caseof FILE API you mentioned. Then how=20
would this idea better that.

I hope you got the general idea: let the viewer provide some abstract=20
> property he wants you to track. I can probably explain better on a=20
> blackboard :-P
>=20

Leonardo does provide tracking a lot of stuff. So other than variables and=
=20
API what other stuff can we track?

Anyway, I think this idea has enough mea t to keep 4 ppl busy; some=20
> visualization could enter regarding the state machines.
>  Some interesting stuff could come up regarding reversing the state=20
> machines and tracking them during the reverse execution.
>  I see this idea as a generalisation of the reverse watchpoints idea, and=
=20
> some (basic) parts of this could be implemented using a small script whic=
h=20
> gives the appropriate reverse watchpoint queries.
>=20

Yup, this idea would help in reverse tracing of the state machine. But we=
=20
had a lot of debate in CODITO about how helpful it would be?

Kalpak Shah.