From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6750 invoked by alias); 8 May 2002 12:48:27 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6729 invoked from network); 8 May 2002 12:48:24 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 8 May 2002 12:48:24 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g48CmHh12611; Wed, 8 May 2002 07:48:17 -0500 Date: Wed, 08 May 2002 05:48:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200205081248.g48CmHh12611@duracef.shout.net> To: charsquarra@hotmail.com, gdb@sources.redhat.com Subject: Re: questions / suggestions about gdb X-SW-Source: 2002-05/txt/msg00072.txt.bz2 > 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