Re: questions / suggestions about gdb

[Petr Sorfa <petrs at caldera dot com>]

Hi,

Yes, there are definitely instances where going to a past state simply
does not work. But keeping those certain limitations in mind, it is
quite possible to go to a past state. As far as I know both the Solaris
SDK debugger and the HP debugger (coupled with GDB as far as I
understand it), support some level of "retracing/retracting" your steps.

I could be wrong, but I think the Solaris debugger allows you to
actually change and recompile the code without having to kill or restart
the process (boggles the mind, but it can be useful in correcting code
in complex applications.)

Rosenberg's "How Debuggers Work" (Wiley, ISBN 0-471-14966-7, 1996)
covers briefly some of these concepts. But the book is in need of an
update with more technical details.

Petr 
> > 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