From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19840 invoked by alias); 17 Jun 2008 21:35:01 -0000 Received: (qmail 19788 invoked by uid 22791); 17 Jun 2008 21:35:01 -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; Tue, 17 Jun 2008 21:34:29 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 7131E3C32E for ; Tue, 17 Jun 2008 14:34:27 -0700 (PDT) Subject: Re: [Reverse debugging] A small demo / test program From: Michael Snyder To: gdb@sourceware.org In-Reply-To: <1213736473.3601.1009.camel@localhost.localdomain> References: <1213736473.3601.1009.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 17 Jun 2008 21:35:00 -0000 Message-Id: <1213738467.3601.1013.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/msg00173.txt.bz2 What is this? Two things -- (1) A test for the new branch of gdb with the reverse debug patch, and (2) A modest "proof of concept" for the idea of making something more useful out of the "gdbreplay" concept. So, gdbreplay is a companion of gdbserver, which allows you to make a log of a remote debugging session and then "play it back" later. Its major limitation is that it will only play back the remote debugging log in exactly the same sequence as the original debugging session. I've written a fairly limited prototype program that can take approximately the same log, and let you play it back more naturally, as if it were actually a "live" executing target (within some limits of course). You can look at the log file (~msnyder/break/break4.trace), and immediately see that it does not closely resemble the original log of the remote protocol traffic -- but that it contains a subset of the same semantic information. This log was generated mostly by hand, but I'm working on a post-processor, and I ultimately don't see any obstacle to using the original log generated by gdb as input to a replayer. Also, for historical reasons, my replayer was built out of 'rda', but I see no technical obstacle to building one either from parts of gdbserver or from scratch. A more complete implementation of this could probably replay all of the remote protocol messages from the log (including those for threads, shared libraries etc.), and not just the registers and memory messages as this one does. -------------------------------------------------------------- For the purpose of testing and demonstrating reverse debug, this demo accepts commands from gdb including: 'g', 'G', 'm', 'M' (register and memory state) 's', 'c', 'bs', 'bc' (step, continue, reverse-step, reverse-continue) 'Z0', 'z0' (software breakpoints) Using those and the saved log, it does a fairly convincing job of pretending to execute a program, both forward and in reverse. The log contains snapshots of the machine stack at every execution stop event, so it is always possible to get a backtrace and to look at local variables. I am thinking about this as a possible way of adding reverse debugging test cases to the gdb test suite. Michael PS: for people who can't log into sourceware.org, next time I'm thinking about hosting on the gcc compile farm (http://gcc.gnu.org/wiki/CompileFarm), but for now you can check everything out from cvs and build it yourself: Patched gdb: msnyder-reverse-20080609-branch Patched rda: msnyder-tracepoint-checkpoint-branch For the test load (the 'break' program and log), see this post: http://sourceware.org/ml/gdb/2005-06/msg00027.html