From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26783 invoked by alias); 17 Jun 2008 21:01:41 -0000 Received: (qmail 26774 invoked by uid 22791); 17 Jun 2008 21:01:40 -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:01:15 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 54E383BF01; Tue, 17 Jun 2008 14:01:13 -0700 (PDT) Subject: [Reverse debugging] A small demo / test program From: Michael Snyder To: gdb@sourceware.org Content-Type: text/plain Date: Tue, 17 Jun 2008 21:01:00 -0000 Message-Id: <1213736473.3601.1009.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/msg00172.txt.bz2 Folks, this is a little demo that I've cooked up, to test and illustrate the ideas of : * reverse debugging (step, continue, breakpoint), and * doing something with the gdbreplay concept. This is mainly aimed at you other gdb maintainers for now, and to make it as easy as possible, I've set everything up to run from my home dir on sourceware.org. If you can log in to sourceware.org, you're golden. If not you'll have to check out and build stuff from cvs, and in the future I'm looking at an alternative hosting site for demos. In a follow-on msg I'll talk about what this is actually doing: for now I'll just outline how to look at the demo. You'll need two login shells on sourceware.org. In the first one, do this: cd ~msnyder/break ../builds/rda/samples/sample -t break4.trace The socket id will default to "2345", but if two of you happen to try to run it at the same time, you'll collide. You can use "1234" or something. And now from the 2nd login shell: cd /home/msnyder/break ../builds/gdb/gdb/gdb break You're now looking at a copy of testsuite/gdb.base/break. Now do this: (gdb) set trust-readonly (gdb) break factorial (gdb) break marker1 (gdb) break marker2 (gdb) break marker3 (gdb) break marker4 (gdb) target remote :2345 (or your chosen socket id) (gdb) tfind start (gdb) continue You should hit the breakpoint at "factorial", and you will be able to do a backtrace and evaluate local variables. You should hit the breakpoint at "factorial", and you will be able to do a backtrace and evaluate local variables. Continue a few more times, as factorial recurses and the stack grows deeper. Backtrace should continue to work. Eventually factorial will return, and you will hit one or more of the breakpoints at marker1, marker2, marker3, and marker4 (in sequence). Now do this: (gdb) reverse-continue This should take you back to the previous breakpoint. You can do this repeatedly, using backtrace to confirm that you are indeed progressing backward through the recursive function calls. You can alternate between "continue" and "reverse-continue" at your discretion. At some point, preferably before you reach the beginning, disable the breakpoints and try this: (gdb) reverse-step Having got the idea by now, you should be able to convince yourself that reverse-step is doing what you would expect, and that you can step backwards all the way to the entry point of main if you so choose. You can alternate between "step" and "reverse-step" at will, and it should do what you would expect it to do. If you run past the end of main, you can simply set a breakpoint anywhere and "reverse-continue" to get back to a known state. If you somehow get hosed, you can use "tfind start" to return to the start state. If you have a chance to try this, I would appreciate hearing about how it goes for you, if you run into any problems etc. Thanks much, Michael PS: In case you're wondering, no child program is actually being executed here. It's all done with mirrors, a recorded execution sequence being replayed from a log. However, gdb does not know this, and the gdb commands (and remote protocol sequences) are real, exactly as they would be for a "real" reverse-execution target such as SID. More in follow-on message.