This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: questions / suggestions about gdb

Ok, thank you for the explanation! ; )

Charles Quarra

>From: Michael Elizabeth Chastain <>
>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.
>   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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]