From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11901 invoked by alias); 1 Sep 2009 13:49:21 -0000 Received: (qmail 11892 invoked by uid 22791); 1 Sep 2009 13:49:19 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk) (212.23.3.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 13:49:14 +0000 Received: from [82.69.137.158] (helo=[10.17.20.102]) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1MiTjQ-00019f-6w; Tue, 01 Sep 2009 13:49:08 +0000 Message-ID: <4A9D2650.6080209@undo-software.com> Date: Tue, 01 Sep 2009 13:49:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Jakob Engblom CC: 'Michael Snyder' , gdb@sourceware.org, Julian Smith Subject: Re: Simics & reverse execution References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> <4A89B7E4.9010804@vmware.com> <027701ca209f$64c71ce0$2e5556a0$@com> <4A95E319.6020300@vmware.com> <4A97B9C9.8070501@greglaw.net> <010b01ca2a3c$7766ca70$66345f50$@com> <4A9BF84F.3070404@undo-software.com> <025201ca2ace$a9256430$fb702c90$@com> In-Reply-To: <025201ca2ace$a9256430$fb702c90$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.69.137.158] 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: 2009-09/txt/msg00002.txt.bz2 Jakob Engblom wrote: >> If the 64 bits of the integer were to be considered 'opaque' and no more >> than a unique handle onto a point in history, that would be fine. But >> such a restriction is unfortunate, because you wouldn't be able to e.g. >> binary chop history. > > But on which side of the debugger connection would you do this? I was assuming it would be driven by the gdb side. One can imagine "smart" targets that allow optimized binary chop type stuff. But it seems reasonable to assume that not all targets will have such smarts. Most important I think is to enable the user to do the binary chop. It might not be a straight-forward thing they're looking for, and in general it would be a very useful thing for the user to be able to say, essentially, "back a bit, back a bit more, forward a bit". For that to work we need some way for gdb to know about and be able to control a point in history relative to other points in history. As I mentioned earlier, a way to convert between an opaque handle and a scalar value would allow this (this is what UndoDB does right now). An alternative take would be to enable gdb to query and set the percentage through recorded history we are right now. That is, use two interfaces: one to get/set an opaque, unique timestamp ID (used for bookmarks) and another to get/set the percentage of the way through the record log we currently are (to allow e.g. a graphical frontend to implement a slide-bar to show where in the record log we are). The former is precise to instruction count (and signals, etc); the latter may not be depending on the details of the target. Actually, percentage is the wrong term -- better would be what fraction of the way are we through history, e.g. in 1/(2^64) increments, such that half way through recorded history would be represented as 2^63. I don't have strong opinions on exactly how the protocol should express this. But I do think we need a "precise" notion of time (e.g. for bookmarks) and a "relative" notion of time (e.g. for displaying a slide-bar in a GUI). If we're to use the same "type" to do both jobs, an 8-byte integer is a bit restrictive. If we're to use different types (probably with conversion between the two), then each being an 8-byte integer is fine. Greg -- Greg Law, Undo Software http://undo-software.com/