From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7477 invoked by alias); 8 May 2002 13:55:15 -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 7463 invoked from network); 8 May 2002 13:55:14 -0000 Received: from unknown (HELO hotmail.com) (209.185.241.67) by sources.redhat.com with SMTP; 8 May 2002 13:55:14 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 May 2002 06:55:14 -0700 Received: from 200.11.240.6 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 08 May 2002 13:55:14 GMT X-Originating-IP: [200.11.240.6] From: "Charles James Leonardo Quarra Cappiello" To: gdb@sources.redhat.com Bcc: Subject: Re: questions / suggestions about gdb Date: Wed, 08 May 2002 06:55:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 May 2002 13:55:14.0951 (UTC) FILETIME=[FAB16970:01C1F697] X-SW-Source: 2002-05/txt/msg00076.txt.bz2 Ok, thank you for the explanation! ; ) Charles Quarra >From: Michael Elizabeth Chastain >To: charsquarra@hotmail.com, gdb@sources.redhat.com >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 >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 _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com