From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3306 invoked by alias); 8 May 2002 13:53:18 -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 3299 invoked from network); 8 May 2002 13:53:17 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 8 May 2002 13:53:17 -0000 Received: from caldera.com (localhost.localdomain [127.0.0.1]) by tetsuo.nj.caldera.com (8.11.6/8.11.6) with ESMTP id g48E55c04181; Wed, 8 May 2002 10:05:05 -0400 Message-ID: <3CD93090.420CCF3E@caldera.com> Date: Wed, 08 May 2002 06:53:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: Michael Elizabeth Chastain CC: charsquarra@hotmail.com, gdb@sources.redhat.com Subject: Re: questions / suggestions about gdb References: <200205081248.g48CmHh12611@duracef.shout.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00075.txt.bz2 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