From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3277 invoked by alias); 7 May 2002 22:18:31 -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 3270 invoked from network); 7 May 2002 22:18:30 -0000 Received: from unknown (HELO hotmail.com) (209.185.241.22) by sources.redhat.com with SMTP; 7 May 2002 22:18:30 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 May 2002 15:18:30 -0700 Received: from 200.11.240.6 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 07 May 2002 22:18:29 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: Tue, 07 May 2002 15:18:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 May 2002 22:18:30.0021 (UTC) FILETIME=[1DF1B350:01C1F615] X-SW-Source: 2002-05/txt/msg00066.txt.bz2 Andrew Cagney wrote: > >>Daniel Jacobowitz wrote: >> >> >>>can i activate the 'generate-core-file' a few steps before the program >>>breaks? >> >>Whenever you want to; you just issue the command, and then you can come >>back to look at the core file later. >> >> >>my question is; how the debugger would automatically know that three steps >>further the program will break and generate a core file; i guess to >>generate core files on every (say, 100 steps) could help a lot too. > >In theory .... In addition to saving the internal state of the program, >you'll need to record all the external state and any additional I/O that >the running program performs. That way you can exactly replay that >program's behavour (this gets tricky when you're trying to to timers >just right). I suspect you'd end up having to use a simulator for this. > Alternativly, you can ignore the external state problem and get >something working most of the time (via something like fork()?). > >Another possability is to have GDB use its builtin-simulator to look >ahead a few instructions at what the inferior would do given its current >state. Provided the simulator doesn't modify the inferior (debugged >process) nor do I/O it shouldn't affect the program that is running. > >enjoy, >Andrew > > But i still think that having two instances of the debugger with a step offset, in which when the one advanced in time breaks, makes the other behind pause, would help a lot, DDD couldn't handle this without much burden? -Charles Quarra _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.