Re: questions / suggestions about gdb

[Michael Elizabeth Chastain <mec@shout.net>]

> 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