This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: questions / suggestions about gdb
- From: "Charles James Leonardo Quarra Cappiello" <charsquarra at hotmail dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 08 May 2002 09:55:14 -0400
- Subject: Re: questions / suggestions about gdb
- Bcc:
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