This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: questions / suggestions about gdb
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: charsquarra at hotmail dot com, gdb at sources dot redhat dot com
- Date: Wed, 8 May 2002 07:48:17 -0500
- Subject: Re: questions / suggestions about gdb
> 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