Menu
▾
▴
lizard-hackers
|
From: Soam V. <soa...@ya...> - 2005-08-29 21:54:07
|
--- Kalpak Shah <kal...@gm...> wrote: > Date: Mon, 29 Aug 2005 12:52:49 -0700 > From: Kalpak Shah <kal...@gm...> > To: soa...@ya... > Subject: CODITO - Reversible debugger > > Hey Soam, > > Our BE project group is working at Codito. We were really inspired > by > LIZARD and have been thinking about reversible debugging. Sameer > asked > me to take your help for doubts regarding reversible debugger. > > 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. There are good tools available > for > checkpointing to minimize the memory requirements, so checkpointing > most probably should not be a problem. Would it be enough, if we > can > provide minimal functionality but prove that it is extensible? > > Sameer also said that even if are able to change variable values in > the executed code, it would be a good enough project. In this case > we > wouldnt need any recompilation. > > 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. > > Thanking you, > Kalpak Shah > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Soam V. <soa...@co...> - 2005-08-29 22:37:37
|
--- Kalpak Shah <kal...@gm...> wrote: > Our BE project group is working at Codito. We were really inspired > by LIZARD and have been thinking about reversible debugging. Sameer > asked me to take your help for doubts regarding reversible debugger. Ok > 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. Which functionality ? Do you want to re-implement lizard ? why ? (re-implementing lizard is not an invalid idea, i'm just asking you why you're considering it.) > There are good tools available for checkpointing to minimize the > memory requirements, so checkpointing most probably should not be a > problem. Would it be enough, if we can provide minimal functionality > but prove that it is extensible? Minimal functionality for what ? Lizard already implements some minimal functionality for a replay debugger, including checkpointing. > Sameer also said that even if are able to change variable values in > the executed code, it would be a good enough project. In this case > we wouldnt need any recompilation. Yeah, allowing users to change variable values during the debug session would be a good feature; i'm not sure it's a big enough BE project. (But we'll certainly help you if you decide to do this.) What is the case you are thinking of that requires recompilation ? > 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. Overall, I haven't really understood your email. What exactly are you looking for ? Please have a look at http://lizard.sourceforge.net/explain.html . If you're looking to extend lizard, we had, i think, thought of 3 new things that would be nice to do: (1) what-if capability i.e. changing variable values (2) supporting multi-threaded programs (3) supporting multi-processor programs. These 3 things are in increasing order of difficulty. There's also the list of bugs at http://sourceforge.net/tracker/?group_id=112369&atid=662041 hope this helps. regards, soam |
|
From: Ramana R. <ram...@gm...> - 2005-08-30 05:15:42
|
You might also be interested in looking at Simics / Virtio Hindsight. They= =20 have done some interesting work. Also there is a branch in the GDB sources= =20 for some similar work. Some of that was done by Michael Snyder. If you do= =20 search the gdb archives you can find references to all of them .=20 http://sources.redhat.com/ml/gdb/2005-05/msg00145.html and the associated thread.=20 Enjoy !=20 cheers Ramana cheers Ramana On 8/30/05, Soam Vasani <soa...@co...> wrote: >=20 > --- Kalpak Shah <kal...@gm...> wrote: > > Our BE project group is working at Codito. We were really inspired > > by LIZARD and have been thinking about reversible debugging. Sameer > > asked me to take your help for doubts regarding reversible debugger. >=20 > Ok >=20 > > 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<http://www.softinteg= ration.com>)=20 > and EiC. EiC can > > be embedded or linked to other programs. We could use it along with > > GDB to provide this functionality. >=20 > Which functionality ? Do you want to re-implement lizard ? why ? > (re-implementing lizard is not an invalid idea, i'm just asking you > why you're considering it.) >=20 > > There are good tools available for checkpointing to minimize the > > memory requirements, so checkpointing most probably should not be a > > problem. Would it be enough, if we can provide minimal functionality > > but prove that it is extensible? >=20 > Minimal functionality for what ? Lizard already implements some > minimal functionality for a replay debugger, including checkpointing. >=20 > > Sameer also said that even if are able to change variable values in > > the executed code, it would be a good enough project. In this case > > we wouldnt need any recompilation. >=20 > Yeah, allowing users to change variable values during the debug > session would be a good feature; i'm not sure it's a big enough BE > project. (But we'll certainly help you if you decide to do this.) >=20 > What is the case you are thinking of that requires recompilation ? >=20 > > 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. >=20 > Overall, I haven't really understood your email. What exactly are you > looking for ? >=20 > Please have a look at http://lizard.sourceforge.net/explain.html . >=20 > If you're looking to extend lizard, we had, i think, thought of 3 > new things that would be nice to do: (1) what-if capability > i.e. changing variable values (2) supporting multi-threaded programs > (3) supporting multi-processor programs. > These 3 things are in increasing order of difficulty. >=20 > There's also the list of bugs at > http://sourceforge.net/tracker/?group_id=3D112369&atid=3D662041 >=20 > hope this helps. >=20 > regards, > soam >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20 > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Lizard-hackers mailing list > Liz...@li... > https://lists.sourceforge.net/lists/listinfo/lizard-hackers >=20 --=20 Ramana Radhakrishnan |
|
From: Ravi R. <ram...@gm...> - 2005-08-30 07:17:58
|
Hi, -- Kalpak Shah <kal...@gm...> 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. --=20 Ravi Ramaseshan " Reality is only something we believe in strongly. " |
|
From: Aditya T. <woo...@ya...> - 2005-08-30 08:18:08
|
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 |
|
From: Soam V. <soa...@co...> - 2005-08-30 17:57:23
|
Aditya Thakur said: > 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! I think i understand the problem you describe... but could you slow down a bit and explain the solution you're proposing ? (1) If we just want to check whether the interface is used correctly, you don't need a replay debugger or any sort of checkpointing, right ? You just trace the program's calls to the interface, and walk the state machine, signalling an error when the state machine shows one. (2) If you want to actually take the user to the place where the error is and allow him to go back/forward, then a regular trace+checkpoint thing is required in addition to checking the state machine; so then this is no cheaper than replay debugging. > 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. ok.. > You can have a few default state machines, but in theory you should let the > used specify it in some, preferably graphical, way. ok > 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 part i didn't understand. > This way the user can change the state machines during the debugging session. nor this. (and also, why would one want to change the state machine during the debug session ?) > OR > Only save enough state (using dynamic slicing) to provide information > regarding the relevant variables affecting the state machines you are > tracking. ok, but i still don't know what you're saving state for in the first place. soam |
|
From: Aditya T. <woo...@ya...> - 2005-08-30 19:12:13
|
--- Soam Vasani <soa...@co...> wrote: > I think i understand the problem you describe... > but could you slow down > a bit and explain the solution you're proposing ? > > (1) If we just want to check whether the interface > is used correctly, you > don't need a replay debugger or any sort of > checkpointing, right ? > You just trace the program's calls to the interface, > and walk the > state machine, signalling an error when the state > machine shows one. > > (2) If you want to actually take the user to the > place where the error is > and allow him to go back/forward, then a regular > trace+checkpoint thing > is required in addition to checking the state > machine; so then this is > no cheaper than replay debugging. These are exactly the 2 methods i proposed: if you know the state machines before you execute you can track just the state machine states. If you dont know the state machines, then all you can do is checkpoint/trace normally (as you said) and do the tracking of the state machine state in the debug session. > > 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 part i didn't understand. > > > This way the user can change the state machines > during the debugging session. > > nor this. (and also, why would one want to change > the state machine during > the debug session ?) > > > OR > > Only save enough state (using dynamic slicing) to > provide information > > regarding the relevant variables affecting the > state machines you are > > tracking. > > ok, but i still don't know what you're saving state > for in the first place. these are the 2 points you mentioned above, which i re-iterated again. another way of looking at it: the states represent some sort of user defined abstractions of the program state. the state might not necessarily represent any error states. for e.g. you can just see if a variable is +ve or -ve, instead of the actual value. so each state is associated with a predicate which depends on certain variables. coming back to the question of what to save: the predicates might be too complicate to evaluate at run-time. so you can just dump the variables which the various states depend on and evaluate the actual state at debug time. another reason you would want to save the variables is that the user might want to see why the machine is in that state for e.g. if your 2 states are SORTED and UNSORTED for an array; then having the array at hand to see which positions are "unsorted" might be usefull to determine the bug. anyway, i'm going too far again. but i hope the main problem is clear: abstract the program state and provide legal moves from one abstract state to the next by specifying predicates on the program state and a finite state machine. the rest you can play around with and see what makes sense. Aditya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Aditya T. <woo...@ya...> - 2005-08-30 19:12:30
|
--- Soam Vasani <soa...@co...> wrote: > I think i understand the problem you describe... > but could you slow down > a bit and explain the solution you're proposing ? > > (1) If we just want to check whether the interface > is used correctly, you > don't need a replay debugger or any sort of > checkpointing, right ? > You just trace the program's calls to the interface, > and walk the > state machine, signalling an error when the state > machine shows one. > > (2) If you want to actually take the user to the > place where the error is > and allow him to go back/forward, then a regular > trace+checkpoint thing > is required in addition to checking the state > machine; so then this is > no cheaper than replay debugging. These are exactly the 2 methods i proposed: if you know the state machines before you execute you can track just the state machine states. If you dont know the state machines, then all you can do is checkpoint/trace normally (as you said) and do the tracking of the state machine state in the debug session. > > 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 part i didn't understand. > > > This way the user can change the state machines > during the debugging session. > > nor this. (and also, why would one want to change > the state machine during > the debug session ?) > > > OR > > Only save enough state (using dynamic slicing) to > provide information > > regarding the relevant variables affecting the > state machines you are > > tracking. > > ok, but i still don't know what you're saving state > for in the first place. these are the 2 points you mentioned above, which i re-iterated again. another way of looking at it: the states represent some sort of user defined abstractions of the program state. the state might not necessarily represent any error states. for e.g. you can just see if a variable is +ve or -ve, instead of the actual value. so each state is associated with a predicate which depends on certain variables. coming back to the question of what to save: the predicates might be too complicate to evaluate at run-time. so you can just dump the variables which the various states depend on and evaluate the actual state at debug time. another reason you would want to save the variables is that the user might want to see why the machine is in that state for e.g. if your 2 states are SORTED and UNSORTED for an array; then having the array at hand to see which positions are "unsorted" might be usefull to determine the bug. anyway, i'm going too far again. but i hope the main problem is clear: abstract the program state and provide legal moves from one abstract state to the next by specifying predicates on the program state and a finite state machine. the rest you can play around with and see what makes sense. Aditya __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Kalpak S. <kal...@gm...> - 2005-09-10 19:00:24
|
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. |
|
From: Aditya T. <woo...@ya...> - 2005-09-11 09:12:59
|
> I didnt find any great C interpreters(other than > EiC) which could be used to > perform the "reverse interpreter" operation. Also we > couldnt come up with > any convincing solution for the problem Ravi > mentioned. Would this be more > beneficial in presence of available reversible > debuggers? I don't know if it would be more beneficial. I also don't remember the problem which ravi described (could you send it to me again). This intepreter idea makes more sense if you look at java or c#, which already have a nice bytecode/il present. The iterpreters for those would be simple (to understand and modify) and freely available. Though this is something you and the ppl in Codito can debate about. Again, reversible debuggers is an old idea now. you have to put in more utility into the whole thing, not just reduce the overheads of tracing. > The checkpointing stuff could be done by > instrumenting the code, and the > graphical depiction of state machines could also be > provided. But in case of > tracking APIs, as it is if there is an error in the > API, the program will > give a runtime error like in the caseof FILE API you > mentioned. Then how > would this idea better that. Maybe you should think of some examples where the API protocol is not followed, yet the program does not (ever/sometimes) give a runtime error. Does opening a file but never closing it make the program crash? an api only specifies how it should be used, certain assumptions are not explicitly mentioned nor do they cause errors. for eg. the api says that the array returned should be sorted, your implementation doesnt do that. it wouldn't cause a program crash, just a wrong result. now the astute reader can say, "use assertions"...but what if you can't compile the code again and again, dont have the sources (only debug info) or whatever. There are static analyses tools which try to solve the api problem. they are pretty nice. you should look them up fyi. > 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 > > > > Leonardo does provide tracking a lot of stuff. So > other than variables and > API what other stuff can we track? You tell me. yup, leonardo does do a lot of nice things. > 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. > > > > Yup, this idea would help in reverse tracing of the > state machine. But we > had a lot of debate in CODITO about how helpful it > would be? > > Kalpak Shah. > If you can't think of any reasons why this is useful, drop the idea and think of smthing else. regards, Aditya ______________________________________________________ Yahoo! for Good Watch the Hurricane Katrina Shelter From The Storm concert http://advision.webevents.yahoo.com/shelter |
|
From: Ravi R. <ram...@gm...> - 2005-09-11 01:10:19
|
Hi, On 9/10/05, Kalpak Shah <kal...@gm...> wrote: > hi aditya,=20 > =20 > I tried to follow up on the leads you gave us.=20 > =20 > On 8/30/05, Aditya Thakur <woo...@ya...> wrote: > >=20 > > 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 Rav= i > spoke about. So instead of generating (like a compiler) the reverse > instructions, you would just do it at runtime (like an interpreter). what > say? >=20 > I didnt find any great C interpreters(other than EiC) which could be use= d > to perform the "reverse interpreter" operation. Also we couldnt come up w= ith > any convincing solution for the problem Ravi mentioned. Would this be mor= e > beneficial in presence of available reversible debuggers? Could you please tell us how do you plan on using a C-interpreter ? What do you want the interpreter to do exactly ? This C-interpreter thing you speak of seems very vague to me. --=20 Ravi Ramaseshan http://www.geocities.com/ramaseshan_ravi/ " Reality is only something we believe in strongly. " |
|
From: Ravi R. <ram...@gm...> - 2005-09-11 01:20:29
|
On 9/10/05, Ravi Ramaseshan <ram...@gm...> wrote: > Hi, >=20 > On 9/10/05, Kalpak Shah <kal...@gm...> wrote: > > hi aditya, > > > > I tried to follow up on the leads you gave us. > > > > On 8/30/05, Aditya Thakur <woo...@ya...> wrote: > > > > > > 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 R= avi > > spoke about. So instead of generating (like a compiler) the reverse > > instructions, you would just do it at runtime (like an interpreter). wh= at > > say? > > > > I didnt find any great C interpreters(other than EiC) which could be u= sed > > to perform the "reverse interpreter" operation. Also we couldnt come up= with > > any convincing solution for the problem Ravi mentioned. Would this be m= ore > > beneficial in presence of available reversible debuggers? >=20 > Could you please tell us how do you plan on using a C-interpreter ? > What do you want the interpreter to do exactly ? This C-interpreter > thing you speak of seems very vague to me. As far as I see it, the C-interpreter thing is just seems to be a place where you're going to actually code/instrument-in your reverse code fragment. This whole discussion is way too vague ! You couldn't find C-interpreters to do what exactly ? What do you mean by "reverse interpretation" ? What is it supposed to interpret ? At what level are you working ? Why do you need a C interpreter ? What is your objective ? --=20 Ravi Ramaseshan http://www.geocities.com/ramaseshan_ravi/ " Reality is only something we believe in strongly. " |
Thanks for helping keep SourceForge clean.
X