From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23414 invoked by alias); 7 May 2002 22:02:08 -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 23388 invoked from network); 7 May 2002 22:02:06 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 7 May 2002 22:02:06 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 55DC23D2B; Tue, 7 May 2002 18:02:11 -0400 (EDT) Message-ID: <3CD84EE3.5040506@cygnus.com> Date: Tue, 07 May 2002 15:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles James Leonardo Quarra Cappiello Cc: gdb@sources.redhat.com Subject: Re: questions / suggestions about gdb References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00064.txt.bz2 > 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