Re: questions / suggestions about gdb

["Charles James Leonardo Quarra Cappiello" <charsquarra@hotmail.com>]

Ok, thank you for the explanation! ; )

Charles Quarra


>From: Michael Elizabeth Chastain <mec@shout.net>
>To: charsquarra@hotmail.com, gdb@sources.redhat.com
>Subject: Re: questions / suggestions about gdb
>Date: Wed, 8 May 2002 07:48:17 -0500
>
> > I'm an often user of gdb, and i was wondering, since debuggers cant go 
>to
> > past states (no inversibility of the run), it would be nice if two 
>instances
> > of the debugger could run synchronized with a given step offset, so when 
>the
> > advanced instance break, the retarded instance stops, keeping an 
>analogous
> > state which can be studied.
>
>This is not feasible.
>
>Suppose that the advanced instance makes a system call, such as reading
>from a network connection.  Later on, the retarded instance will make
>the system call.  How are you going to arrange for the retarded instance
>to receive the same data that the advanced instance received?
>
>Basically, you have to write a wrapping layer that understands every
>system call on the target system.
>
>Besides system calls, you have to handle many other forms of 
>nondeterministic
>instructions:
>
>   signal delivery
>
>     the hard part is not trapping the signal in the advanced process.
>     once the signal is trapped, the hard part is figuring out how many
>     instructions have elapsed in the advanced process so that the signal
>     can be delivered at exactly the right point in the retarded process
>
>   memory-mapped input
>
>     suppose the advanced process reads from a memory-mapped input device.
>     how can you make the device provide the same data a second time,
>     when the retarded process hits it?  At the gdb level, you can't.
>     You need big hooks in the OS memory management code here.
>
>   multi-threading
>
>     If the process is multi-threaded, it is hard to record the thread
>     switches from the advanced process, and it's even harder to make
>     them happen at the same time in the retarded process
>
>I've done work along these lines and I might resume it in the future.
>However, the idea of keeping the "retarded" process running in parallel
>in real time is difficult and unworkable.
>
>Michael C



_________________________________________________________________
Join the worldÂ’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com