From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19977 invoked by alias); 12 Jun 2008 19:39:44 -0000 Received: (qmail 19966 invoked by uid 22791); 12 Jun 2008 19:39:43 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jun 2008 19:39:23 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id DCC1A3C307; Thu, 12 Jun 2008 12:39:21 -0700 (PDT) Subject: Re: Who uses gdbreplay? From: Michael Snyder To: Daniel Jacobowitz Cc: Marc Khouzam , gdb@sourceware.org In-Reply-To: <20080612191849.GA3704@caradoc.them.org> References: <6D19CA8D71C89C43A057926FE0D4ADAA042911BE@ecamlmw720.eamcs.ericsson.se> <1213297921.3601.676.camel@localhost.localdomain> <20080612191849.GA3704@caradoc.them.org> Content-Type: text/plain Date: Thu, 12 Jun 2008 19:39:00 -0000 Message-Id: <1213299561.3601.681.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00120.txt.bz2 On Thu, 2008-06-12 at 15:18 -0400, Daniel Jacobowitz wrote: > On Thu, Jun 12, 2008 at 12:12:01PM -0700, Michael Snyder wrote: > > > This very morning, I was asked if GDB had any kind of foundation for reverse > > > debugging on a target. Is gdbreplay what I am looking for? > > > > Not yet... ;-) > > So... what will the resulting program have in relation to the existing > gdbreplay? It sounds like not much at all. Well I don't want to promise too much too early, but what I have in mind will be VERY different from the current gdbreplay. Rather than requiring you to give exactly the same sequence of gdb commands as during the recording, it will allow you to "step" forward (and eventually backward) thru the log, and pause to examine arbitrary state and issue arbitrary commands at any point along the way. Of course, you can only examine state that was saved during the recording session. In that sense, it will somewhat resemble tracepoint debugging. In fact, I may be able to allow the "tfind" tracepoint commands to work, which would allow you to "skip ahead" (or backward) to an arbitrary point in the log.