This is the mail archive of the
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
Ok, thank you for the explanation! ; )
>From: Michael Elizabeth Chastain <firstname.lastname@example.org>
>To: email@example.com, firstname.lastname@example.org
>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
> > past states (no inversibility of the run), it would be nice if two
> > of the debugger could run synchronized with a given step offset, so when
> > advanced instance break, the retarded instance stops, keeping an
> > 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
> 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.
> 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.
Join the world’s largest e-mail service with MSN Hotmail.