lizard-hackers — Mailing list for Lizard developers

[lizard] The LIZARD has been cited!

[Ravi R. <ram...@gm...>]

We've been cited in a paper 'Reversible Debugging' by  Paul Brook and
Daniel Jacobowitz of
CodeSourcery at GCC Summit 2007.

Here's a link to the proceedings:
http://ols2006.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf

Cheers,
-- 
Ravi Ramaseshan
http://www.geocities.com/ramaseshan_ravi/

" Reality is only something we believe in strongly. "

Re: [lizard] Build error

[Dueway Q. <due...@gm...>]

On 4/6/06, soam vasani <soa...@gm...> wrote:
> On 4/4/06, david.j as <dav...@gm...> wrote:
> > my system :
> > CentOS release 4.2 (Final)
> > 2.6.9-22.0.1.EL  i686 athlon i386 GNU/Linux
>
> > gcc -c -g -O2    -I. -I. -I./config
> > -DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
> > -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
> > -I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
> > -D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
> > -DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
> > -Wparentheses -Wpointer-arith -Wuninitialized  restorer.c
> > restorer.c:8:24: linux/user.h: No such file or directory

I got the same problem on FC4.  I replace <linux/user.h> with
<sys/user.h>, and build it
successfully.

>
> I guess you need to find the glibc headers, can't use the kernel header.
>
> > Is lizard only for kernel 2.4?  Any help would greatly be appreciated!!
>
> AFAIK lizard has only been tested properly with kernel 2.4.
> But if I recall correctly it does build on 2.6.  Anybody ?

I built it on 2.6.11-1.1286_FC4 with a lot of modification to source
code.  GCC-4.0
emit a lot of errors and warnings, so most of modifications are about synta=
x.

There are errors issued by GCC-4.0,

1 GCC-4.0 could not recognize "-fwritable-strings" , so I remove it
from all FLAGS,
and I am not sure side-effect of removing this option.

2 Update insight-5.3/include/obstack.h.  I simply copy obstack.h from
latest libiberty to
overwrite insight-5.3/include/obstack.h,  in order to remove the error
of "lvalue increment".

3 Define USE_PROC_PID_MEM as 0 in trace/config.H.
It seems that copy /proc/<pid>/mem on 2.6 kernel may cause a problem,
and I am still investigating it and learning ptrace now.  It is only a
work-around. :)

Some of these modifications are just hacking, and I am still not clear
about them, so any comments to them are appreicated!

--
Dueway

Re: [lizard] Build error

[soam v. <soa...@gm...>]

On 4/4/06, david.j as <dav...@gm...> wrote:
> my system :
> CentOS release 4.2 (Final)
> 2.6.9-22.0.1.EL  i686 athlon i386 GNU/Linux

> gcc -c -g -O2    -I. -I. -I./config
> -DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
> -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
> -I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
> -D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
> -DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
> -Wparentheses -Wpointer-arith -Wuninitialized  restorer.c
> restorer.c:8:24: linux/user.h: No such file or directory

That's strange.  My Ubuntu system with kernel 2.6.10 has
a /usr/include/linux/user.h.  The file is supposed to come with glibc,
perhaps you're missing a glibc-devel or some such package ?


> If I give this file the location to linux/user.h, via my kernel header fi=
les,
> I get
>
> gcc -c -g -O2    -I. -I. -I./config
> -DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
> -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
> -I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
> -D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
> -DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
> -Wparentheses -Wpointer-arith -Wuninitialized  restorer.c
> -I/usr/src/kernels/2.6.9-22.EL-i686/include/
> In file included from /usr/src/kernels/2.6.9-22.EL-i686/include/asm/page.=
h:4,
>                  from /usr/src/kernels/2.6.9-22.EL-i686/include/asm/user.=
h:4,
>                  from /usr/src/kernels/2.6.9-22.EL-i686/include/linux/use=
r.h:1,
>                  from restorer.c:8:
> /usr/src/kernels/2.6.9-22.EL-i686/include/linux/config.h:6:2: #error
> including kernel header in userspace; use the glibc headers instead!

I guess you need to find the glibc headers, can't use the kernel header.

> Is lizard only for kernel 2.4?  Any help would greatly be appreciated!!

AFAIK lizard has only been tested properly with kernel 2.4.
But if I recall correctly it does build on 2.6.  Anybody ?

regards,
Soam Vasani

[lizard] Build error

[david.j a. <dav...@gm...>]

Hello,

I am having problems building Lizard on my machine here at work,

my system :
CentOS release 4.2 (Final)
2.6.9-22.0.1.EL  i686 athlon i386 GNU/Linux


the error :

gcc -c -g -O2    -I. -I. -I./config
-DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
-I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
-D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
-DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
-Wparentheses -Wpointer-arith -Wuninitialized  blockframe.c
gcc -c -g -O2    -I. -I. -I./config
-DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
-I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
-D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
-DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
-Wparentheses -Wpointer-arith -Wuninitialized  regcache.c
gcc -c -g -O2    -I. -I. -I./config
-DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
-I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
-D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
-DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
-Wparentheses -Wpointer-arith -Wuninitialized  restorer.c
restorer.c:8:24: linux/user.h: No such file or directory
restorer.c: In function `undiffregion':
restorer.c:62: warning: implicit declaration of function `uncompress'
restorer.c:74: warning: implicit declaration of function `memcpy'
restorer.c: In function `get_region_from_chkpt_file':
restorer.c:209: warning: long unsigned int format, unsigned int arg (arg 4)
restorer.c: In function `restore_regs':
restorer.c:422: error: storage size of 'gp' isn't known
make[2]: *** [restorer.o] Error 1
make[2]: Leaving directory `/usr/src/lizard/lizard/insight-5.3/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/usr/src/lizard/lizard/insight-5.3'
make: *** [all] Error 2



If I give this file the location to linux/user.h, via my kernel header file=
s,
I get

gcc -c -g -O2    -I. -I. -I./config
-DLOCALEDIR=3D"\"/home/davidj/replaydebugger/insight/share/locale\""
-DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd
-I./../bfd  -I./../include -I../intl -I./../intl -D_BSD_SOURCE
-D_XOPEN_SOURCE=3D500 -D_LARGEFILE64_SOURCE  -DMI_OUT=3D1 -DGDBTK
-DUI_OUT=3D1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat
-Wparentheses -Wpointer-arith -Wuninitialized  restorer.c
-I/usr/src/kernels/2.6.9-22.EL-i686/include/
In file included from /usr/src/kernels/2.6.9-22.EL-i686/include/asm/page.h:=
4,
                 from /usr/src/kernels/2.6.9-22.EL-i686/include/asm/user.h:=
4,
                 from /usr/src/kernels/2.6.9-22.EL-i686/include/linux/user.=
h:1,
                 from restorer.c:8:
/usr/src/kernels/2.6.9-22.EL-i686/include/linux/config.h:6:2: #error
including kernel header in userspace; use the glibc headers instead!
restorer.c: In function `undiffregion':
restorer.c:62: warning: implicit declaration of function `uncompress'
restorer.c:74: warning: implicit declaration of function `memcpy'
restorer.c: In function `get_region_from_chkpt_file':
restorer.c:209: warning: long unsigned int format, unsigned int arg (arg 4)
restorer.c: In function `restore_regs':
restorer.c:432: warning: unsigned int format, long int arg (arg 2)


Is lizard only for kernel 2.4?  Any help would greatly be appreciated!!

-David

Re: [lizard] Rip off ?

[Ramana R. <ram...@gm...>]

This has been on for quite a while. In fact GDB is getting there with
reverse execution . I believe from the lists that a lot of the work
being done there has the simics in mind.

Not really a rip-off. They have stuff in the simulator and changes by
Michael Snyder are in the target vector AFAIK .



cheers
Ramana

On 1/16/06, Ravi Ramaseshan <ram...@gm...> wrote:
> http://www.virtutech.com/products/simics-hindsight.html
>
> Cheers,
> --
> Ravi Ramaseshan
> http://www.geocities.com/ramaseshan_ravi/
>
> " Reality is only something we believe in strongly. "
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Lizard-hackers mailing list
> Liz...@li...
> https://lists.sourceforge.net/lists/listinfo/lizard-hackers
>


--
Ramana Radhakrishnan

[lizard] Rip off ?

[Ravi R. <ram...@gm...>]

http://www.virtutech.com/products/simics-hindsight.html

Cheers,
--
Ravi Ramaseshan
http://www.geocities.com/ramaseshan_ravi/

" Reality is only something we believe in strongly. "

[lizard] Re: [RFC] a prototype checkpoint-restart using core files

[Michael S. <mic...@ci...>]

Soam Vasani wrote:
> Michael Snyder wrote:
> 
>> Sometimes, as Mark says, a segment hasn't been mmapped
>> in yet.  I don't yet know what to do about that.
> 
> 
> I think the core file doesn't have enough information for
> restoring mmap'd regions ?
> 
> While dumping a checkpoint you could save /proc/pid/maps, and
> do the mmaps before restoring the rest of the state from core file.
> But I'm not sure /proc/pid/maps has enough information, the "flags"
> argument to mmap (thats the 4th one) doesn't seem to be shown there.

Well, I already use /proc/pid/maps to generate the corefile.
That's how I know which memory segments need to be saved.

And I know which ones are writeable (I don't have to save
the ones that aren't).

[lizard] Re: [RFC] a prototype checkpoint-restart using core files

[Soam V. <ss...@co...>]

Michael Snyder wrote:
> Sometimes, as Mark says, a segment hasn't been mmapped
> in yet.  I don't yet know what to do about that.

I think the core file doesn't have enough information for
restoring mmap'd regions ?

While dumping a checkpoint you could save /proc/pid/maps, and
do the mmaps before restoring the rest of the state from core file.
But I'm not sure /proc/pid/maps has enough information, the "flags"
argument to mmap (thats the 4th one) doesn't seem to be shown there.

regards,
soam

Re: [lizard] Re: A few ideas

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

> 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 

Re: [lizard] Re: A few ideas

[Ravi R. <ram...@gm...>]

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. "

Re: [lizard] Re: A few ideas

[Ravi R. <ram...@gm...>]

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. "

[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.

[lizard] Some more general thoughts ...

[prateek s. <jav...@ya...>]

Hi all,

Replay tools have many applications. You guys should
probably spend some time what you want to use the idea
of checkpoint-replay for. 

Directions to go with the LIZARD idea:

1. Implementing Lizard for SMP:

The idea is to first extend it multi-threaded or
multi-process applications. 

Maybe you want to use a virtual machine based thing
first. 


2. Reverse debugging the OS:
There is a project implemented on top of this system
called Revirt, which lets you replay the Linux
Operationg system. Other systems debug User mode Linux
processes as well. They ran into problems like how to
debug architecture-specific code (read more on this),
how to handle interrupts... blah blah. Paper :
Debugging OS with time-travelling virtual machines.


3. System Security:
   Your system has an API, which is meant to have a
certain order in which calls are to be made, and it
expects that calls are made with certain kinds of
arguments. Malicious programs try to attack the
systems by not following the order and coventions of
the API. In such a case you should test run the system
with checkpointing. So, when it crashes ... you can go
back and say... lets see what behaviour did the
malicious program have.
(I think Aditya was saying the same thing, but with
the intent of catching ones own errors)

There are tools that trace certain events such as
system calls made by user programs requesting some
service from the host OS. They have in-built FSM of
what can be the calling order or API calls. So, if a
program deviates from that, they suspect an attack.
Anyway.. its just an idea where they use checkpointing
and revert systems.

4. "What-if" cappability -> 

You could use an interpreter, and revert to some state
before the modified line(say L), and interpret code
with the new instruction stream. Of course, the trace
that we had beyond L is invalidated.

OR

Selectively recompile that module. If u change a
function definition .. u can still revert to a point
before the first time that this function is called. 
So you can avoid using an interpretter.


Any more directions? Any details on the above?

Cheers,
Prateek.


		
_______________________________________________________ 
Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com

Re: [lizard] A few ideas

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

--- 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 

Re: [lizard] A few ideas

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

--- 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 

Re: [Fwd: Re: [lizard] Fwd: CODITO - Reversible debugger]

[soam v. <soa...@gm...>]

> Sameer told me that you guys wanted to make a "reversible debugger for SM=
P
> systems".

ah, ok.  so ?

> We are not thinking of re-implementing Lizard. In case of Lizard if we
> identify an error, we need to make the change and again start debugging
> the  program from line 1.

ok, understood.

> Sameer defined a reversible debugger as in, we should be able to change
> code  at line 75, while line 100 is being executed and then take the flow
> of  execution back to line 75.

ok.  but note that a change of code at line 75 can affect any further
execution of the program.  Therefore even if you go to line 75 after the ch=
ange,
you will have to go to the first occurrence; further occurrences are
not neccesarily
the same after the code-change. =20

Now, your idea in going to the changed code (line 75) was that you help the=
=20
user in debugging the same control flow from a little earlier point in time=
.
However, going to the FIRST occurence of line 75 is very different from goi=
ng to
the correct occurrence of line 75; so when you hit the first line 75 you mi=
ght=20
be very very far in time from the point where the error is; there may be no=
thing
wrong at this point.  So i don't really see the utility of this idea.

As far as implementation goes, you need to analyse a little more before you
discard the idea.  Why is recompilation of code a problem ?  What is
the easiest case, the most difficult case ?  Think of a few simple examples=
=20
and think of how the various components of the replay debugger will be affe=
cted.

Personally, i don't think it is too much work; but it is your project
and you decide
whether you want to do it.

> So they
> are suggesting that we just implement the "what-if"(changing variable
> values) capability you mentioned. I also feel that implementing "what-if"
> capability would not be a big enough BE project.=20

ok

> Right now I am thinking
> about being able to change entire code blocks at runtime. That I feel
> would  be really cool.

see above.  you need to explain how a replay debugger is going to do=20
anything useful with a new, changed, piece of code.

> This functionality is available with Visual Basic because it uses an
> interpreter at debugging stage.

VB has a replay debugger that lets you change code ? cool !
play with it some more, see if the problem i described above makes any
sense, and if VB solves it somehow.

regards
soam

Re: [lizard] A few ideas

[Soam V. <soa...@co...>]

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

[Fwd: Re: [lizard] Fwd: CODITO - Reversible debugger]

[Soam V. <soa...@co...>]

Kalpak, please send your questions to
liz...@li..., not me.

---------------------------- Original Message ----------------------------
Subject: Re: [lizard] Fwd: CODITO - Reversible debugger
From:    "Kalpak Shah" <kal...@gm...>
Date:    Tue, August 30, 2005 9:50 am
To:      "Soam Vasani" <soa...@co...>
--------------------------------------------------------------------------

Hey Soam,

Sameer told me that you guys wanted to make a "reversible debugger for SMP
 systems".

We are not thinking of re-implementing Lizard. In case of Lizard if we 
identify an error, we need to make the change and again start debugging
the  program from line 1.

Sameer defined a reversible debugger as in, we should be able to change
code  at line 75, while line 100 is being executed and then take the flow
of  execution back to line 75.
People are not optimistic about the feasibility of such a project. So they
 are suggesting that we just implement the "what-if"(changing variable 
values) capability you mentioned. I also feel that implementing "what-if" 
capability would not be a big enough BE project. Right now I am thinking 
about being able to change entire code blocks at runtime. That I feel
would  be really cool.

This functionality is available with Visual Basic because it uses an 
interpreter at debugging stage. We are looking at different options to 
implement this.

Thanks,
Kalpak.



On 8/29/05, Soam Vasani <soa...@co...> wrote:
>
> --- 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<http://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
>
>
>



soam

[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 

Re: [lizard] Fwd: CODITO - Reversible debugger

[Ravi R. <ram...@gm...>]

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. "

Re: [lizard] Fwd: CODITO - Reversible debugger

[Ramana R. <ram...@gm...>]

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

Re: [lizard] Fwd: CODITO - Reversible debugger

[Soam V. <soa...@co...>]

--- 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

[lizard] Fwd: CODITO - Reversible debugger

[Soam V. <soa...@ya...>]

--- 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 

Re: [lizard] Some thoughts on lizard

[Andreas E. <eh...@is...>]

On Fri, Jul 08, 2005 at 12:18:16PM +0200, Andreas Ehliar wrote:
> Right now I don't have any details except that it isn't working. I
> will investigate it a bit more during the weekend. Perhaps I'll try it
> on 2.4.25 and see if it works. Anyway, I will get back to you once I
> have investigated the problem a bit more.

I got the tracer program to work on another computer yesterday. It
worked right out of the box, so I don't know why it didn't work on the
first computer I tried it on. (The second used kernel version 2.6.11.5
so it is not a 2.4.x vs 2.6.x problem.)


/Andreas

Re: [lizard] Some thoughts on lizard

[Ravi R. <ram...@gm...>]

Hi,

On 7/8/05, Andreas Ehliar <eh...@is...> wrote:
> (Do you
> handle dlopen/shared libraries in the current version btw?)

No. We currently only support replay debugging of statically linked executa=
bles.

Cheers,
--=20
Ravi Ramaseshan

" All man's miseries derive from not being able to sit in a room alone. "
- Blaise Pascal